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

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

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:
> >>> On Fri, Apr 17, 2026 at 09:49:36AM +0200, Michel Dänzer 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.
> >>>
> >>> GPU reset should relight the display on its own really. That's what
> >>> i915 does, albeit somewhat badly at the moment.
> >>>
> >>>> 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)
> >>>
> >>> There's nothing preventing the kernel from doing extra atomic
> >>> commits whenever it wants.
> >>
> >> I made that same argument at first.
> >>
> >> Then it occurred to me the kernel-internal atomic modeset commit could cause spurious EBUSY failures for user-space atomic commits overlapping with it.
> > 
> > Not so. Everything just gets blocked on the kms mutexes and the -EBUSY 
> > stuff never even comes into play.
> 
> Makes things easier in that case. I followed up accordingly in the other thread.
> 
> 
> >>> But if you want to punt the thing to userspace then the kernel must set the link-status
> >>> property to bad, and then fire the hotplug uevent.
> >>
> >> I later suggested using the link-status property for this as well.
> >>
> >> Checking with others on IRC and reading documentation / code though, I realized my recollection of its semantics was wrong, it actually doesn't look suitable for this. In particular, the expected user space response to link-status bad is to set a *different* mode (since the mode may be relevant for the link failure), not the same one which was already set.
> > 
> > The expected response it to retry with the same mode, at least if
> > that mode is still on the connector's mode list. If the mode got
> > pruned then there's perhaps no point in trying it again.
> 
> On re-reading the link-status documentation in drivers/gpu/drm/drm_connector.c, I agree.
> 
> I'm afraid you're optimistic in terms of user space support for link-status though.
> 
> Neither mutter nor weston even look at it yet.
> 
> KWin reacts to link-status bad with a modeset, not sure it handles the current mode disappearing though. Seems good enough for the scenarios we're discussing here.
> 
> wlroots seems to handle it properly.
> 
> (Any compositors which don't handle it yet need to be fixed, just pointing out it might not make a difference with existing releases of some of them)

I guess someone should start thinking about some kind of KMS conformance
test for compositors. Presumably vkms could provide the kernel part of
that.

-- 
Ville Syrjälä
Intel