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

[Daniel Stone]

Hi Nicolas,

On Tue, 26 May 2026 at 13:39, Nicolas Frattaroli
<nicolas.frattaroli@xxxxxxxxxxxxx> 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.
>
> 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. Future work should however
> make the kernel explicitly request a modeset from userspace through a
> more robust path, either by using link-status (nb. the userspace side
> may not handle it properly at present) or by exposing the epoch counter
> through the uAPI such that fragile state comparison code is no longer
> needed.
>
> This change results in potentially more hotplug events being sent than
> previously, as n changed connectors at a time result in n hotplug
> events, rather than just a single one.

Series is:
Reviewed-by: Daniel Stone <daniels@xxxxxxxxxxxxx>

I'm not sure if Ville is still planning to look at it or not, but I'm
happy to push it if it's all good.

Thanks a lot for working on this!

Cheers,
Daniel