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

[Nicolas Frattaroli <nicolas.frattaroli@collabora.com>]

On Thursday, 16 April 2026 15:55:52 Central European Summer Time Julian Orth wrote:
> On Thu, Apr 16, 2026 at 3:35 PM Marius Vlad <marius.vlad@collabora.com> wrote:
> >
> > On Thu, Apr 16, 2026 at 03:16:39PM +0200, 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:
> > > > > >
> > > > > > I will be taking over this series from Marius Vlad.
> > > > > >
> > > > > > 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
> > With this change you wouldn't need to go over all of them as the kernel
> > will supply the connector ID that has changed.
> 
> Is this change only going to add the connector property to existing
> events or will it send additional events with the connector property
> set?

It sends additional events if you happen to have multiple connectors
undergoing a hotplug at the same time. This should not be a cause for
concern; it's bounded by the number of connectors in the system (which
is a single digit number, usually).

Kind regards,
Nicolas Frattaroli