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

[Michel Dänzer]

On 4/16/26 15:16, Julian Orth wrote:
> On Thu, Apr 16, 2026 at 9:46 AM Nicolas Frattaroli
> <nicolas.frattaroli@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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.


P.S. https://gitlab.freedesktop.org/drm/i915/kernel/-/work_items/14420#note_2984697 even argued that two modesets are required after a hotplug event, one which turns things off and another one which turns them on again. I don't agree with that though, a single modeset should suffice.


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