[Intel-gfx] [PATCH v7 09/11] drm: uevent for connector status change

[Ser, Simon]

On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote:
> On Mon, 13 May 2019 11:34:58 +0200
> Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> 
> > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski
> > <paul.kocialkowski at bootlin.com> wrote:
> > > Hi,
> > > 
> > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote:  
> > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski
> > > > <paul.kocialkowski at bootlin.com> wrote:  
> > > > > Hi,
> > > > > 
> > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote:  
> > > > > > DRM API for generating uevent for a status changes of connector's
> > > > > > property.
> > > > > > 
> > > > > > This uevent will have following details related to the status change:
> > > > > > 
> > > > > >   HOTPLUG=1, CONNECTOR=<connector_id> and PROPERTY=<property_id>
> > > > > > 
> > > > > > Need ACK from this uevent from userspace consumer.  
> > > > > 
> > > > > So we just had some discussions over on IRC and at about the hotplug
> > > > > issue and came up with similar ideas:
> > > > > https://lists.freedesktop.org/archives/dri-devel/2019-May/217408.html
> > > > > 
> > > > > The conclusions of these discussions so far would be to have a more or
> > > > > less fine grain of uevent reporting depending on what happened. The
> > > > > point is that we need to cover different cases:
> > > > > - one or more properties changed;
> > > > > - the connector status changed;
> > > > > - something else about the connector changed (e.g. EDID/modes)
> > > > > 
> > > > > For the first case, we can send out:
> > > > > HOTPLUG=1
> > > > > CONNECTOR=<id>
> > > > > PROPERTY=<id>
> > > > > 
> > > > > and no reprobe is required.
> > > > > 
> > > > > For the second one, something like:
> > > > > HOTPLUG=1
> > > > > CONNECTOR=<id>
> > > > > STATUS=Connected/Disconnected
> > > > > 
> > > > > and a connector probe is needed for connected, but not for
> > > > > disconnected;
> > > > > 
> > > > > For the third one, we can only indicate the connector:
> > > > > HOTPLUG=1
> > > > > CONNECTOR=<id>
> > > > > 
> > > > > and a reprobe of the connector is always needed  
> > > > 
> > > > There's no material difference between this one and the previous one.
> > > > Plus there's no beenfit in supplying the actual value of the property,
> > > > i.e. we can reuse the same PROPERTY=<id-of-status-property> trick.  
> > > 
> > > That's the idea, but we need to handle status changes differently than
> > > properties, since as far as I know, connected/unconnected status is not
> > > exposed as a prop for the connector.  
> > 
> > Oops, totally missed that. "Everything is a property" is kinda
> > new-ish, at least compared to kms. Kinda tempted to just make status
> > into a property. Or another excuse why we should expose the epoch
> > property :-)
> 
> Hi Daniel,
> 
> just to clarify the first case, specific to one very particular
> property:
> 
> With HDCP, there is a property that may change dynamically at runtime
> (the undesired/desired/enabled tristate). Userspace must be notified
> when it changes, I do not want userspace have to poll that property
> with a timer.
> 
> When that property alone changes, and userspace is prepared to handle
> that property changing alone, it must not trigger a reprobe of the
> connector. There is no reason to reprobe at that point AFAIU.
> 
> How do you ensure that userspace can avoid triggering a reprobe with the
> epoch approach or with any alternate uevent design?
> 
> We need an event to userspace that indicates that re-reading the
> properties is enough and reprobe of the connector is not necessary.
> This is complementary to indicating to userspace that only some
> connectors need to be reprobed instead of everything.

Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, skip the
reprobing. Would that work?