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

["Michel Dänzer" <michel.daenzer@mailbox.org>]

On 4/17/26 16:25, Alex Deucher wrote:
> On Fri, Apr 17, 2026 at 3:49 AM Michel Dänzer
> <michel.daenzer@mailbox.org> wrote:
>> On 4/16/26 15:16, Julian Orth wrote:
>>> On Thu, Apr 16, 2026 at 9:46 AM Nicolas Frattaroli
>>> <nicolas.frattaroli@collabora.com> wrote:
>>>> On Wednesday, 15 April 2026 20:57:53 Central European Summer Time Julian Orth wrote:
>>>>> On Wed, Apr 15, 2026 at 8:19 PM Nicolas Frattaroli
>>>>> <nicolas.frattaroli@collabora.com> wrote:
>>>>>>
>>>>>> This series addresses a shortcoming whereby a hot plug event is sent
>>>>>> without it being passed the actual connector that caused it. This takes
>>>>>> into consideration both the polling path and the HPD (Hot Plug Detect)
>>>>>> path. It also adds support for the vkms driver (using ConfigFS) for
>>>>>> propagating the connector ID when changing the connector's status.
>>>>>>
>>>>>> The motivation is that user-space applications such as Weston would
>>>>>> previously receive non-connector-specific hotplug events, and then have
>>>>>> to figure out themselves which connector needs to have a modeset
>>>>>> executed on. This notably did not work when the hotplug events came in
>>>>>> too fast, resulting in Weston missing an on-off-on transition of a
>>>>>> connector, seeing that its state was unchanged from "on" so can't be the
>>>>>> one that was hotplugged, and skipping reinitialising it as it looks
>>>>>> through the other connectors that could've caused it.
>>>>>
>>>>> Have you considered adding a u64 serial number as a DRM connector
>>>>> property that is incremented every time the connector changes in some
>>>>> way? Userspace could then check this serial number to see if the
>>>>> connector has changed since the last time it queried the serial
>>>>> number.
>>>>
>>>> The connector internally already has an epoch_counter member which
>>>> could be used for this. However, for the particular thing this
>>>> series fixes, I don't think exposing it through the uAPI is necessary
>>>> or desirable. Sending hotplug events specific to the connector does
>>>> not need any additional handling on the userspace side as long as it
>>>> already listens to the per-connector hotplug events in order to
>>>> avoid the pitfall described in the cover letter.
>>>
>>> I currently do not handle per-connector hotplug events. Instead,
>>> whenever I get a UDEV change event for a device, I re-fetch the entire
>>> kernel state for the device. That is
>>>
>>> - DRM_IOCTL_MODE_GETRESOURCES
>>> - DRM_IOCTL_MODE_OBJ_GETPROPERTIES for each connector, crtc, plane
>>> - DRM_IOCTL_MODE_GETCONNECTOR for each connector
>>> - DRM_IOCTL_MODE_GETPROPERTY for each connector property
>>> - DRM_IOCTL_MODE_GETPROPBLOB for the EDID
>>>
>>> Once I have the new state, I compare it against the desired compositor
>>> state and perform a modeset if necessary.
>>
>> mutter is doing something similar as well.
>>
>>
>> Note that some are arguing a modeset is always required after a hotplug event, even if the state hasn't changed.
>>
>> The most convincing argument I've seen is the scenario of a GPU reset, after which a modeset is required to light up the displays again. A hotplug event seems the only mechanism available for the kernel to request a modeset from the compositor. (The kernel may not be able to reliably do the modeset on its own, e.g. due to interactions with user-space atomic commits)
>>
>>
>> If this "modeset required after hotplug event" rule is confirmed, it means that after a hotplug event without connector ID, the compositor must do a modeset for all connectors.
>>
> 
> One thing we've run into is how to deal with hotplugs over suspend.
> If you suspend your system, amdgpu sends a hotplug event on resume in
> case anything got changed while the system was suspended.  However, we
> can also suspend the driver at runtime and we use the same path so
> when the driver runtime resumes, it also sends a hotplug event.  This
> is probably fine in most cases, but there are some problematic corner
> cases.  E.g., while the GPU is runtime suspended, if the monitors are
> in DPMS off, and then a rendering command comes in or something else
> that wakes the GPU, we send a hotplug event on resume and then
> userspace lights up the monitors again which is not what the user
> wants if the monitors are in DPMS off and the topology hasn't changed.

I should have been more specific: "after a hotplug event without connector ID, the compositor must do a modeset for all connectors *when it wants them to be on*", i.e. not necessarily immediately, and only for connectors it wants to be on.


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