Re: [PATCH RESEND v7 0/2] Pass down hot-plug CONNECTOR ID to user-space

[Michel Dänzer]

On 4/17/26 20:50, Ville Syrjälä wrote:
> On Fri, Apr 17, 2026 at 06:40:51PM +0200, Michel Dänzer wrote:
>> On 4/17/26 16:55, Ville Syrjälä wrote:
>>> On Fri, Apr 17, 2026 at 04:17:45PM +0200, Michel Dänzer wrote:
>>>> On 4/17/26 12:57, Ville Syrjälä wrote:
>>>>>>>>>> I think the userspace behaviour there was that you get a disconnected,
>>>>> defer processing it, and then you get a reconnect, and then decide that
>>>>> nothing actually changed and a modeset is not needed after all. That is
>>>>> not correct IMO. Clearly a ->disconnect->reconnect should count as a
>>>>> change in the connector's state, and a full modeset is thus required.
>>>>
>>>> While that makes sense to me in principle, as Julian pointed out, the kernel can't rely on user space seeing the intermittent disconnected state.
>>>>
>>>> Seems like another argument for a serial number property. That would make the need for a modeset unambiguous.
>>>
>>> [...]
>>>
>>> But for the case where the kernel only sends the per-connector uevents
>>> and the drm master sees all of them the serial number would do nothing.
>>> In that case the kernel wouldn't even send the uevent unless the
>>> serial number has changed.
>>
>> The serial number is still necessary in cases where status flip-flops connected → disconnected → connected, user space never sees the disconnected state though.
> 
> I suppose that could happen if the flip flop is fast enough that the
> status has changed back to connected by the time userspace gets to
> process the first uevent. Although the fact that the uevent was sent
> in the first place (assuming it's the per-connector one) would imply
> that something did in fact change.

There are cases where hotplug events get triggered despite nothing changing from the user PoV,
e.g. due to monitors polling their other inputs. Reacting to such hotplug events can have various undesirable side effects, that's why compositors are trying to avoid it.

> But I do agree that having a clear signal in the form of the changed serial
> number would avoid a lot of weird guesswork in userspace.

Either that, or setting link-status to bad, yeah.

In the scenario we're discussing here, the latter might be even clearer actually, since a modeset isn't always required.


>>>> Note that the referenced issue is about a different scenario though:
>>>>
>>>> 1. mutter does modeset for DPMS off
>>>> 2. hotplug events during DPMS off (presumably triggered by the monitor scanning its inputs)
>>>> 3. mutter does modeset for DPMS on
>>>>
>>>> The monitor stays off after step 3. The argument in the comment I referenced is that mutter should repeat step 1 before step 3.
>>>
>>> That can't be it. We don't do anything if you try to disable an already  
>>> disabled output. And the analysis of the logs indicated that the disable
>>> (DPMS off) was completely missing.
>> The mutter debug log in https://gitlab.gnome.org/GNOME/mutter/-/issues/4145#note_2457199 disagrees.
> 
> I only see two modeset commits in that log. Both with CRTC 134 being
> enabled with connector 250. So far I can't find any DPMS off in there.
> Am I just blind?

It's subtle, line 12498:

[...] gnome-shell[2418]: KMS: [atomic] Committing disable-device transaction

(The issue is about the monitor not turning on after DPMS off, i.e. it does enter DPMS off in the first place :)

I do see now that the hotplug events happen only after mutter's modeset for DPMS on though (I previously mistook that for the modeset for DPMS off). The second modeset is presumably after switching to another VT and back.


In summary, the link-status property seems the best mechanism for solving this issue. I filed https://gitlab.gnome.org/GNOME/mutter/-/work_items/4760 about handling it in mutter.


-- 
Earthling Michel Dänzer       \        GNOME / Xwayland / Mesa developer
https://redhat.com             \               Libre software enthusiast