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

[Pekka Paalanen]

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.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20190514/a2401ca6/attachment-0001.sig>