Hi Nicolas, On Tue, 26 May 2026 at 13:39, Nicolas Frattaroli <[email protected]> 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 <[email protected]> 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
