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@xxxxxxxx> wrote: > > > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski > > <paul.kocialkowski@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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? _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
