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

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

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.

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@collabora.com>
> > ---
> > 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@collabora.com
> >
> > 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@collabora.com
> >
> > 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@collabora.com/
> >
> > 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@collabora.com/
> >
> > 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@intel.com/
> > - 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@collabora.com/
> >
> > 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@collabora.com/
> >
> > 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@collabora.com/
> >
> > ---
> > 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@collabora.com>
> >
>