Improving DRM connector hotplug uevents

[Ser, Simon]

On Fri, 2019-05-10 at 09:56 +0200, Daniel Vetter wrote:
> On Fri, May 10, 2019 at 9:42 AM Paul Kocialkowski
> <paul.kocialkowski at bootlin.com> wrote:
> > Hi,
> > 
> > So this thread has drifted off from IGT to a general DRM improvement,
> > so renaming the thread and adding some CCs.
> > 
> > It's about avoiding full reprobes (which may include slow EDID reads,
> > etc) when a connector change was detected, by providing information
> > about the connector and the new state to userspace. This way, userspace
> > can reprobe the changed connector alone (or not reprobe at all in case
> > of a disconnect).
> > 
> > It feels like there is growing temptation to have per-driver hacks to
> > avoid full reprobes when the driver knows that nothing changed, but I
> > think it makes more sense to fixup the uevent we send to make sure that
> > userspace knows what to probe exactly.
> > 
> > On Fri, 2019-05-10 at 06:55 +0000, Ser, Simon wrote:
> > > On Thu, 2019-05-09 at 11:56 -0400, Lyude Paul wrote:
> > > > I'm in support of this as well, we really could use better hotplug events.
> > > > Feel free to cc patches to me for review :)
> > > 
> > > Any idea(s) how the API would look like?
> > 
> > From a quick chat on IRC yesterday, it seems that just adding entries
> > to the uevent would do and would be backwards-compatible (well,
> > provided that the userspace uevent parsers will not fail if something
> > extra to "HOTPLUG=1" is provided).
> > 
> > Currently, the notification is sent globally at each round of detected
> > connector change (which may concern multiple connectors). So I think we
> > should just list the connectors that changed in the uevent and their
> > new state. So my proposal here is something like:
> > 
> > HOTPLUG=1
> > CONNECTOR_ID=47
> > STATUS=Connected
> > CONNECTOR_ID=48
> > STATUS=Disconnected
> > 
> > Where each STATUS entry would refer to the previous CONNECTOR_ID entry.
> > 
> > What do you think?
> 
> We have the better uevent already, all we need is wiring up, lots of
> code, and userspace for it. Ok, not quite, patch is still in flight:
> 
> https://patchwork.kernel.org/patch/10906677/

Excellent.

I can help with a userspace implementation if needed.