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

[Marius Vlad]

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@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:
> > > >
> > > > 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.
> - 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.
> 
> This makes it robust against the situation you're describing, but also
> means that a lot of work is done for unchanged objects. If the change
> makes a modeset necessary, then that work is almost negligible
> compared to the time the modeset takes.
> 
> I don't know if your patches will cause more change events to be sent
> or if they will just add the connector property to existing events. If
> there are additional events, then I'd prefer to have an early out for
> some of this work. E.g. by having access to the epoch_counter.
> 
> >
> > Kind regards,
> > Nicolas Frattaroli
> >
> > > >
> > > > The real world implication is that on setups with slightly sketchy HDMI
> > > > connections, a brief flicker in the HPD signal could result in video
> > > > output bidding farewell entirely until a manual proper re-plug was
> > > > performed.
> > > >
> > > > By sending connector specific hotplug events, this ambiguity is
> > > > resolved without any change to the user-space API.
> > > >
> > > > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@xxxxxxxxxxxxx>
> > > > ---
> > > > Changes in v7 RESEND:
> > > > - None, other than removing the leftover diffstat from the cover letter
> > > > - Link to v7: https://lore.kernel.org/r/20260217-hot-plug-passup-v7-0-f8221b2aab51@xxxxxxxxxxxxx
> > > >
> > > > Changes in v7:
> > > > - Drop the two vkms patches, as I don't want them to be blocked on
> > > >   review. I still think they're correct, but they're not essential and
> > > >   don't need to block this series.
> > > > - Link to v6: https://lore.kernel.org/r/20260123-hot-plug-passup-v6-0-aaaf61d960bb@xxxxxxxxxxxxx
> > > >
> > > > Changes in v6:
> > > > - Rewrote cover letter to explain the motivation for this series more
> > > >   plainly
> > > > - Rename "status_changed" to "pending_hp"
> > > > - Set "pending_hp" in the existing path that would also affect
> > > >   epoch_counter
> > > > - No longer set the boolean in drm_helper_probe_single_connector_modes,
> > > >   as it does not appear to be necessary
> > > > - Reword commits to better justify the changes
> > > > - Link to v5: https://lore.kernel.org/r/20251111162338.15141-1-marius.vlad@xxxxxxxxxxxxx/
> > > >
> > > > Changes in v5:
> > > > - vkms: add support for sending the CONNECTOR ID when hot-plugging through
> > > >   ConfigFS - as reported by Louis, vkms can now make use of ConfigFS to
> > > >   simulate connector status.
> > > > - vkms: add a small change to ignore previous/old drm connector status
> > > >   when sending out hot-plug uevent.
> > > > - Link to v4: https://lore.kernel.org/r/20251103174558.7709-1-marius.vlad@xxxxxxxxxxxxx/
> > > >
> > > > Changes in v4:
> > > > - removed the "This patch" bit - Dmitry
> > > > - added a short note when the flag is set and cleared - Dmitry
> > > > - address double dead-locking detected - kbot: https://lore.kernel.org/dri-devel/202509251410.fdfbcac3-lkp@xxxxxxxxx/
> > > > - virtual connectors do not seem have any kind of hotplug - added
> > > >   polling in vkms - as noted by Ian
> > > > - Link to v3: https://lore.kernel.org/r/20250923083636.4749-1-marius.vlad@xxxxxxxxxxxxx/
> > > >
> > > > Changes in v3:
> > > > - Address comments from Dmitry:
> > > >   - guard connector status write with mode_config.mutex
> > > >   - avoid setting up the connector status and immediately unset it. Do the
> > > >     unset in drm_kms_helper_hotplug_event/drm_kms_helper_connector_hotplug_event
> > > > - Link to v2: https://lore.kernel.org/r/20250729165708.9947-1-marius.vlad@xxxxxxxxxxxxx/
> > > >
> > > > Changes in v2:
> > > > - Address comments from Daniel:
> > > >   - split patch into 2, one that introduces a bool to track connector
> > > >     connection status change and a patch that uses that to be able to send
> > > >     hot plug events with the proper CONNECTOR ID to udev and further pass
> > > >     that down to user-space
> > > >   - nuke out mutex when iterating connector list
> > > >   - fix typo
> > > > - Link to v1: https://lore.kernel.org/r/20250627131751.2004-1-marius.vlad@xxxxxxxxxxxxx/
> > > >
> > > > ---
> > > > Marius Vlad (2):
> > > >       drm: Introduce pending_hp to drm_connector
> > > >       drm: Send per-connector hotplug events
> > > >
> > > >  drivers/gpu/drm/drm_connector.c    |  1 +
> > > >  drivers/gpu/drm/drm_probe_helper.c | 39 +++++++++++++++++++++++++++++++++-----
> > > >  drivers/gpu/drm/drm_sysfs.c        |  2 ++
> > > >  include/drm/drm_connector.h        |  3 +++
> > > >  4 files changed, 40 insertions(+), 5 deletions(-)
> > > > ---
> > > > base-commit: 4c59525db84aca677fd9f052e662912ad9d88448
> > > > change-id: 20260121-hot-plug-passup-f8ed03f7c202
> > > >
> > > > Best regards,
> > > > --
> > > > Nicolas Frattaroli <nicolas.frattaroli@xxxxxxxxxxxxx>
> > > >
> > >
> >
> >
> >
> >

Attachment: signature.asc
Description: PGP signature