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

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

[Nicolas Frattaroli]

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.

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>

[PATCH RESEND v7 1/2] drm: Introduce pending_hp to drm_connector

[Nicolas Frattaroli]

From: Marius Vlad <marius.vlad@collabora.com>

Introduce a new boolean variable used to track whether a connector has
changed its status since the last hotplug event for it was sent to
userspace. It is used by both the polling and HPD path.

A subsequent change will make use of this new member to propagate
per-connector udev hotplug events to userspace, rather than sending a
global hotplug event.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 drivers/gpu/drm/drm_connector.c    |  1 +
 drivers/gpu/drm/drm_probe_helper.c | 17 +++++++++++++++++
 drivers/gpu/drm/drm_sysfs.c        |  2 ++
 include/drm/drm_connector.h        |  3 +++
 4 files changed, 23 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 3fa4d2082cd7..b1abdef6778a 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -274,6 +274,7 @@ static int drm_connector_init_only(struct drm_device *dev,
 
 	/* provide ddc symlink in sysfs */
 	connector->ddc = ddc;
+	connector->pending_hp = false;
 
 	INIT_LIST_HEAD(&connector->head);
 	INIT_LIST_HEAD(&connector->global_connector_list_entry);
diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
index d4dc8cb45bce..f8cbd6713960 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -732,6 +732,17 @@ EXPORT_SYMBOL(drm_helper_probe_single_connector_modes);
  */
 void drm_kms_helper_hotplug_event(struct drm_device *dev)
 {
+	struct drm_connector *connector;
+	struct drm_connector_list_iter conn_iter;
+
+	mutex_lock(&dev->mode_config.mutex);
+	drm_connector_list_iter_begin(dev, &conn_iter);
+	drm_for_each_connector_iter(connector, &conn_iter) {
+		connector->pending_hp = false;
+	}
+	drm_connector_list_iter_end(&conn_iter);
+	mutex_unlock(&dev->mode_config.mutex);
+
 	drm_sysfs_hotplug_event(dev);
 	drm_client_dev_hotplug(dev);
 }
@@ -748,6 +759,10 @@ void drm_kms_helper_connector_hotplug_event(struct drm_connector *connector)
 {
 	struct drm_device *dev = connector->dev;
 
+	mutex_lock(&dev->mode_config.mutex);
+	connector->pending_hp = false;
+	mutex_unlock(&dev->mode_config.mutex);
+
 	drm_sysfs_connector_hotplug_event(connector);
 	drm_client_dev_hotplug(dev);
 }
@@ -837,6 +852,7 @@ static void output_poll_execute(struct work_struct *work)
 				    old_epoch_counter, connector->epoch_counter);
 
 			changed = true;
+			connector->pending_hp = true;
 		}
 	}
 	drm_connector_list_iter_end(&conn_iter);
@@ -1101,6 +1117,7 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
 				first_changed_connector = connector;
 			}
 
+			connector->pending_hp = true;
 			changed++;
 		}
 	}
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index ef4e923a8728..47a6b322e873 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -216,6 +216,8 @@ static ssize_t status_store(struct device *device,
 			    connector->base.id, connector->name,
 			    old_force, connector->force);
 
+		connector->pending_hp = true;
+
 		connector->funcs->fill_modes(connector,
 					     dev->mode_config.max_width,
 					     dev->mode_config.max_height);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 3e422a4f2e72..70a740301089 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -2251,6 +2251,9 @@ struct drm_connector {
 	/** @force: a DRM_FORCE_<foo> state for forced mode sets */
 	enum drm_connector_force force;
 
+	/** @pending_hp: true if connector changed since last hotplug event */
+	bool pending_hp;
+
 	/**
 	 * @edid_override: Override EDID set via debugfs.
 	 *

-- 
2.53.0

[PATCH RESEND v7 2/2] drm: Send per-connector hotplug events

[Nicolas Frattaroli]

From: Marius Vlad <marius.vlad@collabora.com>

Use the new pending_hp member of drm_connector to always send
per-connector hotplug events for those connectors that need it, rather
than sending a global event, or only an event for one connector.

On the HPD (Hot Plug Detect) path this change notifies all connectors,
rather than just first changed connector.

The polling path is changed to no longer send a connector-less hotplug
event, but similarly send a hotplug event for each changed connector.

Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
 drivers/gpu/drm/drm_probe_helper.c | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
index f8cbd6713960..5c39f27ada1d 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -860,8 +860,14 @@ static void output_poll_execute(struct work_struct *work)
 	mutex_unlock(&dev->mode_config.mutex);
 
 out:
-	if (changed)
-		drm_kms_helper_hotplug_event(dev);
+	if (changed) {
+		drm_connector_list_iter_begin(dev, &conn_iter);
+		drm_for_each_connector_iter(connector, &conn_iter) {
+			if (connector->pending_hp)
+				drm_kms_helper_connector_hotplug_event(connector);
+		}
+		drm_connector_list_iter_end(&conn_iter);
+	}
 
 	if (repoll)
 		schedule_delayed_work(delayed_work, DRM_OUTPUT_POLL_PERIOD);
@@ -1124,10 +1130,16 @@ bool drm_helper_hpd_irq_event(struct drm_device *dev)
 	drm_connector_list_iter_end(&conn_iter);
 	mutex_unlock(&dev->mode_config.mutex);
 
-	if (changed == 1)
+	if (changed == 1) {
 		drm_kms_helper_connector_hotplug_event(first_changed_connector);
-	else if (changed > 0)
-		drm_kms_helper_hotplug_event(dev);
+	} else if (changed > 0) {
+		drm_connector_list_iter_begin(dev, &conn_iter);
+		drm_for_each_connector_iter(connector, &conn_iter) {
+			if (connector->pending_hp)
+				drm_kms_helper_connector_hotplug_event(connector);
+		}
+		drm_connector_list_iter_end(&conn_iter);
+	}
 
 	if (first_changed_connector)
 		drm_connector_put(first_changed_connector);

-- 
2.53.0

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

[Julian Orth]

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 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>
>

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

[Nicolas Frattaroli]

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>
> >
> 

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

[Julian Orth]

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
- 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@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>
> > >
> >
>
>
>
>

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

[Marius Vlad]

[-- Attachment #1: Type: text/plain, Size: 7848 bytes --]

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.
> - 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@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>
> > > >
> > >
> >
> >
> >
> >

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Julian Orth]

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?

> > - 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@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>
> > > > >
> > > >
> > >
> > >
> > >
> > >

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

[Nicolas Frattaroli]

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

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

[Julian Orth]

On Thu, Apr 16, 2026 at 4:22 PM Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
>
> 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).

If the number of udev events stays the same in the
single-connector-hotplug case, then I guess this change is a strict
improvement.

Having access to the serial would still be more efficient in the
scenario you described since then the compositor could see that the
second event is a no-op.

>
> Kind regards,
> Nicolas Frattaroli
>
>

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@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. 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

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

[Ville Syrjälä]

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. 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.

> 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.

Only for connectors where things changed, or the link-status shows bad.

> 
> 
> 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.

The actual argument is that you should not defer the hotplug
handling when things get disconnected, mainly because of crap type-c
firmware.

I think the userspace behaviour there was that you get a disconnected,
defer processing it, and then you get a reconnect, and then decide that
nothing actually changed and a modeset is not needed after all. That is
not correct IMO. Clearly a ->disconnect->reconnect should count as a
change in the connector's state, and a full modeset is thus required.
The kernel can of course then decide that the full modeset is not
actually required and skip the modeset part during the commit. But
userspace cannot make that determination.

I suppose what we could maybe do there to force userspace's hand is set
the link-status to bad already when the thing gets disconnected, and keep
it like that until a full disable+re-enable cycle has been done. Then
userspace could not think that the ->disconnect->reconnect is a NOP
(which I still think is incorrect behaviour).

-- 
Ville Syrjälä
Intel

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

[Julian Orth]

On Fri, Apr 17, 2026 at 12:58 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> 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. 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.
>
> > 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.
>
> Only for connectors where things changed, or the link-status shows bad.
>
> >
> >
> > 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.
>
> The actual argument is that you should not defer the hotplug
> handling when things get disconnected, mainly because of crap type-c
> firmware.
>
> I think the userspace behaviour there was that you get a disconnected,
> defer processing it, and then you get a reconnect, and then decide that
> nothing actually changed and a modeset is not needed after all. That is
> not correct IMO. Clearly a ->disconnect->reconnect should count as a
> change in the connector's state, and a full modeset is thus required.

The connector state, AIUI from userspace, is the set of all DRM
connector properties. If the true state changes in a way that requires
userspace to act but the DRM properties are unchanged, then I would
argue that that is a kernel bug.

The link-status property seems like it is perfect for this.

> The kernel can of course then decide that the full modeset is not
> actually required and skip the modeset part during the commit. But
> userspace cannot make that determination.
>
> I suppose what we could maybe do there to force userspace's hand is set
> the link-status to bad already when the thing gets disconnected, and keep
> it like that until a full disable+re-enable cycle has been done. Then
> userspace could not think that the ->disconnect->reconnect is a NOP
> (which I still think is incorrect behaviour).
>
> --
> Ville Syrjälä
> Intel

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

[Julian Orth]

On Fri, Apr 17, 2026 at 12:58 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> 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. 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.
>
> > 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.
>
> Only for connectors where things changed, or the link-status shows bad.
>
> >
> >
> > 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.
>
> The actual argument is that you should not defer the hotplug
> handling when things get disconnected, mainly because of crap type-c
> firmware.
>
> I think the userspace behaviour there was that you get a disconnected,
> defer processing it, and then you get a reconnect, and then decide that
> nothing actually changed and a modeset is not needed after all. That is
> not correct IMO. Clearly a ->disconnect->reconnect should count as a
> change in the connector's state, and a full modeset is thus required.
> The kernel can of course then decide that the full modeset is not
> actually required and skip the modeset part during the commit. But
> userspace cannot make that determination.
>
> I suppose what we could maybe do there to force userspace's hand is set
> the link-status to bad already when the thing gets disconnected, and keep
> it like that until a full disable+re-enable cycle has been done. Then
> userspace could not think that the ->disconnect->reconnect is a NOP
> (which I still think is incorrect behaviour).

I don't think the kernel can make the assumption that userspace sees
any udev events. For example, say such a disconnect/reconnect cycle
happens that leaves the connector in a state that would require two
modeset. Nobody acts on these modesets and some time later the
compositor starts. Obviously the compositor is not going to receive
any udev events for the disconnect/reconnect cycle that happened long
ago. This would leave the connector in a permanently unusable state.

>
> --
> Ville Syrjälä
> Intel

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

[Nicolas Frattaroli]

On Friday, 17 April 2026 12:57:58 Central European Summer Time 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. 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.
> 
> > 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.
> 
> Only for connectors where things changed, or the link-status shows bad.
> 
> > 
> > 
> > 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.
> 
> The actual argument is that you should not defer the hotplug
> handling when things get disconnected, mainly because of crap type-c
> firmware.
> 
> I think the userspace behaviour there was that you get a disconnected,
> defer processing it, and then you get a reconnect, and then decide that
> nothing actually changed and a modeset is not needed after all. That is
> not correct IMO. Clearly a ->disconnect->reconnect should count as a
> change in the connector's state, and a full modeset is thus required.
> The kernel can of course then decide that the full modeset is not
> actually required and skip the modeset part during the commit. But
> userspace cannot make that determination.

So just to loop around to the patches here: is sending per-connector
hotplug events not acceptable? Your review[1] on v5 indicated you had
a problem with the implementation, not a fundamental issue with the
behaviour the patch tried to change.

> I suppose what we could maybe do there to force userspace's hand is set
> the link-status to bad already when the thing gets disconnected, and keep
> it like that until a full disable+re-enable cycle has been done. Then
> userspace could not think that the ->disconnect->reconnect is a NOP
> (which I still think is incorrect behaviour).

The documentation of drm_connector_set_link_status_property explicitly
states:

    * Note: Drivers cannot rely on userspace to support this property and
    * issue a modeset. As such, they may choose to handle issues (like
    * re-training a link) without userspace's intervention.

which I think conflicts with your suggestion.

Kind regards,
Nicolas Frattaroli

https://lore.kernel.org/dri-devel/aROKwmZxFt52g4ed@intel.com/ [1]

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

[Ville Syrjälä]

On Fri, Apr 17, 2026 at 02:42:36PM +0200, Nicolas Frattaroli wrote:
> On Friday, 17 April 2026 12:57:58 Central European Summer Time 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. 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.
> > 
> > > 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.
> > 
> > Only for connectors where things changed, or the link-status shows bad.
> > 
> > > 
> > > 
> > > 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.
> > 
> > The actual argument is that you should not defer the hotplug
> > handling when things get disconnected, mainly because of crap type-c
> > firmware.
> > 
> > I think the userspace behaviour there was that you get a disconnected,
> > defer processing it, and then you get a reconnect, and then decide that
> > nothing actually changed and a modeset is not needed after all. That is
> > not correct IMO. Clearly a ->disconnect->reconnect should count as a
> > change in the connector's state, and a full modeset is thus required.
> > The kernel can of course then decide that the full modeset is not
> > actually required and skip the modeset part during the commit. But
> > userspace cannot make that determination.
> 
> So just to loop around to the patches here: is sending per-connector
> hotplug events not acceptable? Your review[1] on v5 indicated you had
> a problem with the implementation, not a fundamental issue with the
> behaviour the patch tried to change.

What I was saying is that we already have the epoch_counter. If
there are gaps in the implementation then those should just be
fixed. We don't want a second implementation of the same
mechanism.

> 
> > I suppose what we could maybe do there to force userspace's hand is set
> > the link-status to bad already when the thing gets disconnected, and keep
> > it like that until a full disable+re-enable cycle has been done. Then
> > userspace could not think that the ->disconnect->reconnect is a NOP
> > (which I still think is incorrect behaviour).
> 
> The documentation of drm_connector_set_link_status_property explicitly
> states:
> 
>     * Note: Drivers cannot rely on userspace to support this property and
>     * issue a modeset. As such, they may choose to handle issues (like
>     * re-training a link) without userspace's intervention.
> 
> which I think conflicts with your suggestion.

In i915 we do the retraining in kernel. IIRC we only really use the bad
link stuff once retraining has failed hard enough that userspace
intervention is needed, ie. when we cannot reduce the link parameters
anymore without userspace selecting a mode with a lower resolution.

I think some more recent drivers may have opted to forego all in kernel
retraining and just punt it all to userspace. I think the link-status
property has existed for long enough that any userspace that doesn't
support it could simply be considered broken.

Actually I know of a single "userspace" that to my knowledge doesn't
implement the link-status stuff, and that is the in kernel fb helper.
That should probably be remedied...

-- 
Ville Syrjälä
Intel

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

[Michel Dänzer]

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.


> 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.


>> 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.
> 
> The actual argument is that you should not defer the hotplug
> handling when things get disconnected, mainly because of crap type-c
> firmware.
> 
> I think the userspace behaviour there was that you get a disconnected,
> defer processing it, and then you get a reconnect, and then decide that
> nothing actually changed and a modeset is not needed after all. That is
> not correct IMO. Clearly a ->disconnect->reconnect should count as a
> change in the connector's state, and a full modeset is thus required.

While that makes sense to me in principle, as Julian pointed out, the kernel can't rely on user space seeing the intermittent disconnected state.

Seems like another argument for a serial number property. That would make the need for a modeset unambiguous.


Note that the referenced issue is about a different scenario though:

1. mutter does modeset for DPMS off
2. hotplug events during DPMS off (presumably triggered by the monitor scanning its inputs)
3. mutter does modeset for DPMS on

The monitor stays off after step 3. The argument in the comment I referenced is that mutter should repeat step 1 before step 3.


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

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

[Alex Deucher]

On Fri, Apr 17, 2026 at 3:49 AM Michel Dänzer
<michel.daenzer@mailbox.org> 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. 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.
>

One thing we've run into is how to deal with hotplugs over suspend.
If you suspend your system, amdgpu sends a hotplug event on resume in
case anything got changed while the system was suspended.  However, we
can also suspend the driver at runtime and we use the same path so
when the driver runtime resumes, it also sends a hotplug event.  This
is probably fine in most cases, but there are some problematic corner
cases.  E.g., while the GPU is runtime suspended, if the monitors are
in DPMS off, and then a rendering command comes in or something else
that wakes the GPU, we send a hotplug event on resume and then
userspace lights up the monitors again which is not what the user
wants if the monitors are in DPMS off and the topology hasn't changed.

Alex

>
> 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

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

[Michel Dänzer]

On 4/17/26 16:25, Alex Deucher wrote:
> On Fri, Apr 17, 2026 at 3:49 AM Michel Dänzer
> <michel.daenzer@mailbox.org> 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. 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.
>>
> 
> One thing we've run into is how to deal with hotplugs over suspend.
> If you suspend your system, amdgpu sends a hotplug event on resume in
> case anything got changed while the system was suspended.  However, we
> can also suspend the driver at runtime and we use the same path so
> when the driver runtime resumes, it also sends a hotplug event.  This
> is probably fine in most cases, but there are some problematic corner
> cases.  E.g., while the GPU is runtime suspended, if the monitors are
> in DPMS off, and then a rendering command comes in or something else
> that wakes the GPU, we send a hotplug event on resume and then
> userspace lights up the monitors again which is not what the user
> wants if the monitors are in DPMS off and the topology hasn't changed.

I should have been more specific: "after a hotplug event without connector ID, the compositor must do a modeset for all connectors *when it wants them to be on*", i.e. not necessarily immediately, and only for connectors it wants to be on.


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

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

[Ville Syrjälä]

On Fri, Apr 17, 2026 at 02:36:11PM +0200, Julian Orth wrote:
> On Fri, Apr 17, 2026 at 12:58 PM Ville Syrjälä
> <ville.syrjala@linux.intel.com> 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. 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.
> >
> > > 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.
> >
> > Only for connectors where things changed, or the link-status shows bad.
> >
> > >
> > >
> > > 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.
> >
> > The actual argument is that you should not defer the hotplug
> > handling when things get disconnected, mainly because of crap type-c
> > firmware.
> >
> > I think the userspace behaviour there was that you get a disconnected,
> > defer processing it, and then you get a reconnect, and then decide that
> > nothing actually changed and a modeset is not needed after all. That is
> > not correct IMO. Clearly a ->disconnect->reconnect should count as a
> > change in the connector's state, and a full modeset is thus required.
> > The kernel can of course then decide that the full modeset is not
> > actually required and skip the modeset part during the commit. But
> > userspace cannot make that determination.
> >
> > I suppose what we could maybe do there to force userspace's hand is set
> > the link-status to bad already when the thing gets disconnected, and keep
> > it like that until a full disable+re-enable cycle has been done. Then
> > userspace could not think that the ->disconnect->reconnect is a NOP
> > (which I still think is incorrect behaviour).
> 
> I don't think the kernel can make the assumption that userspace sees
> any udev events. For example, say such a disconnect/reconnect cycle
> happens that leaves the connector in a state that would require two
> modeset. Nobody acts on these modesets and some time later the
> compositor starts. Obviously the compositor is not going to receive
> any udev events for the disconnect/reconnect cycle that happened long
> ago. This would leave the connector in a permanently unusable state.

I'm not sure why those outputs would even be enabled if there is
no one around to do kms stuff? Though I suppose there might be some
race conditions if you are switching drm masters exactly when the
uevents are sent.

We do have a sort of plan to always do the disconnect disable from
the kernel, but we can't just disable everything the normal way
as we're not allowed to corrupt the uapi kms state. So the idea
is we'd disable everything internally, and fake it so that
userspace still sees it as enabled. But no one has actually
implemented this so far.

A potential short term solution might be to disable+re-enable
(in our current fallback tbt mode) automagically on disconnect.
But that extra re-enable is not something we actually want in
case userspace is going to do its job properly. Instead of
having one disable modeset on disconnect, we'd always end up
with disable+re-enable+disable. Though I suppose one option
would be to defer the internal disable+re-enable a little bit
to give userspace some time to do its job.

-- 
Ville Syrjälä
Intel

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

[Ville Syrjälä]

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.

> 
> 
> > 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.

That's if the mode was on the connector's mode list to begin with.
If it was never there then just blindly retrying it again seems
like the correct option to me.

> 
> 
> >> 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.
> > 
> > The actual argument is that you should not defer the hotplug
> > handling when things get disconnected, mainly because of crap type-c
> > firmware.
> > 
> > I think the userspace behaviour there was that you get a disconnected,
> > defer processing it, and then you get a reconnect, and then decide that
> > nothing actually changed and a modeset is not needed after all. That is
> > not correct IMO. Clearly a ->disconnect->reconnect should count as a
> > change in the connector's state, and a full modeset is thus required.
> 
> While that makes sense to me in principle, as Julian pointed out, the kernel can't rely on user space seeing the intermittent disconnected state.
> 
> Seems like another argument for a serial number property. That would make the need for a modeset unambiguous.

I guess it could at least optimize the "has this connector changed?"
check for the single uevent without connector IDs case. 

And I suppose it could avoid race conditions with switching drm masters
when the new master can't be sure it's seen all the uevents. Another
thing that would avoid the issues here is if each new master was
required to do one full modeset on everything. But maybe that was never
a rule?

But for the case where the kernel only sends the per-connector uevents
and the drm master sees all of them the serial number would do nothing.
In that case the kernel wouldn't even send the uevent unless the
serial number has changed.

> 
> 
> Note that the referenced issue is about a different scenario though:
> 
> 1. mutter does modeset for DPMS off
> 2. hotplug events during DPMS off (presumably triggered by the monitor scanning its inputs)
> 3. mutter does modeset for DPMS on
> 
> The monitor stays off after step 3. The argument in the comment I referenced is that mutter should repeat step 1 before step 3.

That can't be it. We don't do anything if you try to disable an already  
disabled output. And the analysis of the logs indicated that the disable
(DPMS off) was completely missing.

-- 
Ville Syrjälä
Intel

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

[Nicolas Frattaroli]

On Friday, 17 April 2026 16:16:01 Central European Summer Time Ville Syrjälä wrote:
> On Fri, Apr 17, 2026 at 02:42:36PM +0200, Nicolas Frattaroli wrote:
> > On Friday, 17 April 2026 12:57:58 Central European Summer Time 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. 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.
> > > 
> > > > 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.
> > > 
> > > Only for connectors where things changed, or the link-status shows bad.
> > > 
> > > > 
> > > > 
> > > > 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.
> > > 
> > > The actual argument is that you should not defer the hotplug
> > > handling when things get disconnected, mainly because of crap type-c
> > > firmware.
> > > 
> > > I think the userspace behaviour there was that you get a disconnected,
> > > defer processing it, and then you get a reconnect, and then decide that
> > > nothing actually changed and a modeset is not needed after all. That is
> > > not correct IMO. Clearly a ->disconnect->reconnect should count as a
> > > change in the connector's state, and a full modeset is thus required.
> > > The kernel can of course then decide that the full modeset is not
> > > actually required and skip the modeset part during the commit. But
> > > userspace cannot make that determination.
> > 
> > So just to loop around to the patches here: is sending per-connector
> > hotplug events not acceptable? Your review[1] on v5 indicated you had
> > a problem with the implementation, not a fundamental issue with the
> > behaviour the patch tried to change.
> 
> What I was saying is that we already have the epoch_counter. If
> there are gaps in the implementation then those should just be
> fixed. We don't want a second implementation of the same
> mechanism.

epoch_counter is explicitly documented as "used to detect any other changes
in connector, besides status". pending_hp is changed if the status changes.

If we use epoch_counter for this, I think we'll need to keep track of the
last epoch_counter an hpd was sent for each connector, so we wouldn't win
anything in reduced state being tracked.

> > 
> > > I suppose what we could maybe do there to force userspace's hand is set
> > > the link-status to bad already when the thing gets disconnected, and keep
> > > it like that until a full disable+re-enable cycle has been done. Then
> > > userspace could not think that the ->disconnect->reconnect is a NOP
> > > (which I still think is incorrect behaviour).
> > 
> > The documentation of drm_connector_set_link_status_property explicitly
> > states:
> > 
> >     * Note: Drivers cannot rely on userspace to support this property and
> >     * issue a modeset. As such, they may choose to handle issues (like
> >     * re-training a link) without userspace's intervention.
> > 
> > which I think conflicts with your suggestion.
> 
> In i915 we do the retraining in kernel. IIRC we only really use the bad
> link stuff once retraining has failed hard enough that userspace
> intervention is needed, ie. when we cannot reduce the link parameters
> anymore without userspace selecting a mode with a lower resolution.
> 
> I think some more recent drivers may have opted to forego all in kernel
> retraining and just punt it all to userspace. I think the link-status
> property has existed for long enough that any userspace that doesn't
> support it could simply be considered broken.

Is breaking userspace a better choice than sending per-connector hotplug
events rather than a single global hotplug event? I get where you're
coming from, in that userspace should not be trying to optimise away
modesets, as that's something the kernel can do in a race-free way. I'm
just not familiar enough with the landscape to know whether setting
link-status to bad will actually result in userspace doing a modeset,
and whether drivers in practice then optimise that modeset away if it
wasn't needed.

> Actually I know of a single "userspace" that to my knowledge doesn't
> implement the link-status stuff, and that is the in kernel fb helper.
> That should probably be remedied...

Kind regards,
Nicolas Frattaroli

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

[Ville Syrjälä]

On Fri, Apr 17, 2026 at 05:00:10PM +0200, Nicolas Frattaroli wrote:
> On Friday, 17 April 2026 16:16:01 Central European Summer Time Ville Syrjälä wrote:
> > On Fri, Apr 17, 2026 at 02:42:36PM +0200, Nicolas Frattaroli wrote:
> > > On Friday, 17 April 2026 12:57:58 Central European Summer Time 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. 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.
> > > > 
> > > > > 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.
> > > > 
> > > > Only for connectors where things changed, or the link-status shows bad.
> > > > 
> > > > > 
> > > > > 
> > > > > 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.
> > > > 
> > > > The actual argument is that you should not defer the hotplug
> > > > handling when things get disconnected, mainly because of crap type-c
> > > > firmware.
> > > > 
> > > > I think the userspace behaviour there was that you get a disconnected,
> > > > defer processing it, and then you get a reconnect, and then decide that
> > > > nothing actually changed and a modeset is not needed after all. That is
> > > > not correct IMO. Clearly a ->disconnect->reconnect should count as a
> > > > change in the connector's state, and a full modeset is thus required.
> > > > The kernel can of course then decide that the full modeset is not
> > > > actually required and skip the modeset part during the commit. But
> > > > userspace cannot make that determination.
> > > 
> > > So just to loop around to the patches here: is sending per-connector
> > > hotplug events not acceptable? Your review[1] on v5 indicated you had
> > > a problem with the implementation, not a fundamental issue with the
> > > behaviour the patch tried to change.
> > 
> > What I was saying is that we already have the epoch_counter. If
> > there are gaps in the implementation then those should just be
> > fixed. We don't want a second implementation of the same
> > mechanism.
> 
> epoch_counter is explicitly documented as "used to detect any other changes
> in connector, besides status".

That's just some nonsense that got in by accident. It was always
meant to be a "did anything for this connector change?" type of thing.

Looks like the bogus docs were part of the original commit, but
it even disagrees with the commit message itself.

> pending_hp is changed if the status changes.
> 
> If we use epoch_counter for this, I think we'll need to keep track of the
> last epoch_counter an hpd was sent for each connector, so we wouldn't win
> anything in reduced state being tracked.

What's wrong with just looking at the epoch before and after the detect?

> 
> > > 
> > > > I suppose what we could maybe do there to force userspace's hand is set
> > > > the link-status to bad already when the thing gets disconnected, and keep
> > > > it like that until a full disable+re-enable cycle has been done. Then
> > > > userspace could not think that the ->disconnect->reconnect is a NOP
> > > > (which I still think is incorrect behaviour).
> > > 
> > > The documentation of drm_connector_set_link_status_property explicitly
> > > states:
> > > 
> > >     * Note: Drivers cannot rely on userspace to support this property and
> > >     * issue a modeset. As such, they may choose to handle issues (like
> > >     * re-training a link) without userspace's intervention.
> > > 
> > > which I think conflicts with your suggestion.
> > 
> > In i915 we do the retraining in kernel. IIRC we only really use the bad
> > link stuff once retraining has failed hard enough that userspace
> > intervention is needed, ie. when we cannot reduce the link parameters
> > anymore without userspace selecting a mode with a lower resolution.
> > 
> > I think some more recent drivers may have opted to forego all in kernel
> > retraining and just punt it all to userspace. I think the link-status
> > property has existed for long enough that any userspace that doesn't
> > support it could simply be considered broken.
> 
> Is breaking userspace a better choice than sending per-connector hotplug
> events rather than a single global hotplug event? I get where you're
> coming from, in that userspace should not be trying to optimise away
> modesets, as that's something the kernel can do in a race-free way. I'm
> just not familiar enough with the landscape to know whether setting
> link-status to bad will actually result in userspace doing a modeset,
> and whether drivers in practice then optimise that modeset away if it
> wasn't needed.

I'm not suggesting using link-status for normal hotplug events
where something on the connector actually changed. In those cases
userspace should really be doing a full modeset anyway.

> 
> > Actually I know of a single "userspace" that to my knowledge doesn't
> > implement the link-status stuff, and that is the in kernel fb helper.
> > That should probably be remedied...
> 
> Kind regards,
> Nicolas Frattaroli
> 

-- 
Ville Syrjälä
Intel

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

[Michel Dänzer]

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 think the userspace behaviour there was that you get a disconnected,
>>> defer processing it, and then you get a reconnect, and then decide that
>>> nothing actually changed and a modeset is not needed after all. That is
>>> not correct IMO. Clearly a ->disconnect->reconnect should count as a
>>> change in the connector's state, and a full modeset is thus required.
>>
>> While that makes sense to me in principle, as Julian pointed out, the kernel can't rely on user space seeing the intermittent disconnected state.
>>
>> Seems like another argument for a serial number property. That would make the need for a modeset unambiguous.
> 
> [...]
> 
> But for the case where the kernel only sends the per-connector uevents
> and the drm master sees all of them the serial number would do nothing.
> In that case the kernel wouldn't even send the uevent unless the
> serial number has changed.

The serial number is still necessary in cases where status flip-flops connected → disconnected → connected, user space never sees the disconnected state though.


>> Note that the referenced issue is about a different scenario though:
>>
>> 1. mutter does modeset for DPMS off
>> 2. hotplug events during DPMS off (presumably triggered by the monitor scanning its inputs)
>> 3. mutter does modeset for DPMS on
>>
>> The monitor stays off after step 3. The argument in the comment I referenced is that mutter should repeat step 1 before step 3.
> 
> That can't be it. We don't do anything if you try to disable an already  
> disabled output. And the analysis of the logs indicated that the disable
> (DPMS off) was completely missing.
The mutter debug log in https://gitlab.gnome.org/GNOME/mutter/-/issues/4145#note_2457199 disagrees.


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

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

[Ville Syrjälä]

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 think the userspace behaviour there was that you get a disconnected,
> >>> defer processing it, and then you get a reconnect, and then decide that
> >>> nothing actually changed and a modeset is not needed after all. That is
> >>> not correct IMO. Clearly a ->disconnect->reconnect should count as a
> >>> change in the connector's state, and a full modeset is thus required.
> >>
> >> While that makes sense to me in principle, as Julian pointed out, the kernel can't rely on user space seeing the intermittent disconnected state.
> >>
> >> Seems like another argument for a serial number property. That would make the need for a modeset unambiguous.
> > 
> > [...]
> > 
> > But for the case where the kernel only sends the per-connector uevents
> > and the drm master sees all of them the serial number would do nothing.
> > In that case the kernel wouldn't even send the uevent unless the
> > serial number has changed.
> 
> The serial number is still necessary in cases where status flip-flops connected → disconnected → connected, user space never sees the disconnected state though.

I suppose that could happen if the flip flop is fast enough that the
status has changed back to connected by the time userspace gets to
process the first uevent. Although the fact that the uevent was sent
in the first place (assuming it's the per-connector one) would imply
that something did in fact change. But I do agree that having a clear
signal in the form of the changed serial number would avoid a lot of
weird guesswork in userspace.

> >> Note that the referenced issue is about a different scenario though:
> >>
> >> 1. mutter does modeset for DPMS off
> >> 2. hotplug events during DPMS off (presumably triggered by the monitor scanning its inputs)
> >> 3. mutter does modeset for DPMS on
> >>
> >> The monitor stays off after step 3. The argument in the comment I referenced is that mutter should repeat step 1 before step 3.
> > 
> > That can't be it. We don't do anything if you try to disable an already  
> > disabled output. And the analysis of the logs indicated that the disable
> > (DPMS off) was completely missing.
> The mutter debug log in https://gitlab.gnome.org/GNOME/mutter/-/issues/4145#note_2457199 disagrees.

I only see two modeset commits in that log. Both with CRTC 134 being
enabled with connector 250. So far I can't find any DPMS off in there.
Am I just blind?

-- 
Ville Syrjälä
Intel