From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pekka Paalanen Subject: Re: [PATCH v7 09/11] drm: uevent for connector status change Date: Tue, 14 May 2019 16:36:02 +0300 Message-ID: <20190514163602.7d252b12@eldfell.localdomain> References: <20190507162745.25600-1-ramalingam.c@intel.com> <20190507162745.25600-10-ramalingam.c@intel.com> <31dad9a323382628911c5301a6eec179855aa815.camel@bootlin.com> <8aa3980a6948b9b2b989c237f8453ca54e72ad95.camel@bootlin.com> <20190514110242.6f6ba4b0@eldfell.localdomain> <9b6386239ecae396fc4f5cc4467f8e76721f2c83.camel@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0798456817==" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Daniel Vetter Cc: "paul.kocialkowski@bootlin.com" , "maxime.ripard@bootlin.com" , "intel-gfx@lists.freedesktop.org" , "dri-devel@lists.freedesktop.org" , "Mun, Gwan-gyeong" , "Ser, Simon" , "airlied@linux.ie" , "thomas.petazzoni@bootlin.com" , "Vetter, Daniel" , "sean@poorly.run" List-Id: dri-devel@lists.freedesktop.org --===============0798456817== Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/P5t9xemXHAgk_b6t2Sx4khH"; protocol="application/pgp-signature" --Sig_/P5t9xemXHAgk_b6t2Sx4khH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 14 May 2019 13:02:09 +0200 Daniel Vetter wrote: > On Tue, May 14, 2019 at 10:18 AM Ser, Simon wrote: > > > > On Tue, 2019-05-14 at 11:02 +0300, Pekka Paalanen wrote: =20 > > > On Mon, 13 May 2019 11:34:58 +0200 > > > Daniel Vetter wrote: > > > =20 > > > > On Mon, May 13, 2019 at 11:02 AM Paul Kocialkowski > > > > wrote: =20 > > > > > Hi, > > > > > > > > > > On Fri, 2019-05-10 at 16:54 +0200, Daniel Vetter wrote: =20 > > > > > > On Fri, May 10, 2019 at 2:12 PM Paul Kocialkowski > > > > > > wrote: =20 > > > > > > > Hi, > > > > > > > > > > > > > > On Tue, 2019-05-07 at 21:57 +0530, Ramalingam C wrote: =20 > > > > > > > > DRM API for generating uevent for a status changes of conne= ctor's > > > > > > > > property. > > > > > > > > > > > > > > > > This uevent will have following details related to the stat= us change: > > > > > > > > > > > > > > > > HOTPLUG=3D1, CONNECTOR=3D and PROPERTY=3D > > > > > > > > > > > > > > > > Need ACK from this uevent from userspace consumer. =20 > > > > > > > > > > > > > > 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/217= 408.html > > > > > > > > > > > > > > The conclusions of these discussions so far would be to have = a more or > > > > > > > less fine grain of uevent reporting depending on what happene= d. 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=3D1 > > > > > > > CONNECTOR=3D > > > > > > > PROPERTY=3D > > > > > > > > > > > > > > and no reprobe is required. > > > > > > > > > > > > > > For the second one, something like: > > > > > > > HOTPLUG=3D1 > > > > > > > CONNECTOR=3D > > > > > > > STATUS=3DConnected/Disconnected > > > > > > > > > > > > > > and a connector probe is needed for connected, but not for > > > > > > > disconnected; > > > > > > > > > > > > > > For the third one, we can only indicate the connector: > > > > > > > HOTPLUG=3D1 > > > > > > > CONNECTOR=3D > > > > > > > > > > > > > > and a reprobe of the connector is always needed =20 > > > > > > > > > > > > There's no material difference between this one and the previou= s one. > > > > > > Plus there's no beenfit in supplying the actual value of the pr= operty, > > > > > > i.e. we can reuse the same PROPERTY=3D t= rick. =20 > > > > > > > > > > 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. =20 > > > > > > > > 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 :-) =20 > > > > > > 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. =20 > > > > Can't you use the PROPERTY hint? If PROPERTY is the HDCP one, skip the > > reprobing. Would that work? =20 Hi, yes, that would work, if it was acceptable to DRM upstream. The replies to Paul seemed to be going south so fast that I thought we wouldn't get any new uevent fields in favour of "epoch counters". > Yes that's the idea, depending upon which property you get you know > it's a sink change (needs full reprobe) or something else like hdcp > state machinery update. Right. > Wrt avoiding the full reprobe for sink changes: I think we should > indeed decouple that from the per-connector event for sink changes. > That along is a good win already, since you know for which connector > you need to call drmGetConnector (which forces the reprobe). It would > be nice to only call drmGetConnectorCurrent (avoids the reprobe), but > historically speaking every time we tried to rely on this we ended up > regretting things. What changed? This sounds very much what Paul suggested. Looking at it from userspace side: HOTPLUG=3D1 CONNECTOR=3Dxx PROPERTY=3Dyy - If yy is "Content Protection", no need to drmModeGetConnector(), just re-get the connector properties. - Kernel probably shouldn't bother sending this for properties where re-probe could be necessary, and send the below instead. HOTPLUG=3D1 CONNECTOR=3Dxx - Needs to drmModeGetConnector() on the one connector, no need to probe others. Implies that one needs to re-get the connector properties as well. HOTPLUG=3D1 - Need to do drmModeGetResouces() to discover new/disappeared connectors, and need to drmModeGetConnector to re-probe every connector. (As always.) That should be also backwards-compatible: any userspace that doesn't understand CONNECTOR will see HOTPLUG=3D1 and re-probe everything. Any userspace that doesn't understand PROPERTY or the property it refers to will fall back to probing either the connector or everything. I would be happy to get that behaviour into Weston, particularly as the HDCP feature is brewing for Weston too. -------- When discussing this in IRC, I had the concern about how uevents are delivered in userspace. Is there a possibility that they might be overwritten, contain stale attributes, or get squashed together? Particularly if a display server is current on the VT and active and monitoring udev, but stuck doing something and cannot service uevents very fast, and the kernel sends more than one event before the process gets back to dispatching. The terminology in libudev API confused me as an event is a device. Squashing together would make sense if the uevent were just updating a device attribute list. Previously when we had just a single kind of uevent, that would not have made a difference, but if we gain different kinds of uevents like here, it starts to matter. However, Paul came to the conclusion that we will be ok as long as the events come via netlink. Thanks, pq --Sig_/P5t9xemXHAgk_b6t2Sx4khH Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEJQjwWQChkWOYOIONI1/ltBGqqqcFAlzaxEIACgkQI1/ltBGq qqcceA//cfWlk/DuUob8blOFM49kvwc1TkgHceYJLMuK4JhqUYri6+7jgv+tLM00 fBNiNyw36r+98UsDfaZnB2R7w9EFJQyjd+0Ol6vnCCF3GZbLWzX6f/eo1wX6fBV0 Hdv6X05hB1jndsWnk8FkwCE8KwkSOvIWsyeDdRVeaEGhWChVJ7owUubrYt/JK1dF PkhUr3krmaKbBwkbbwtbKyqjvYpLHH5P3+yDsDt+cdtWhsJMsq/odys11bsK3gE2 moQ4iRDjDDnyEHCVvO/1iNHvtau2q9sevGa352YisBuTi5PdgQ9I3BZj9Q023GDN TcQ8dUF+95R0CP0ZC8mxt1Hd69JIVvgJ1zn7Yvt6DQMdv1Kuh2Aqz7vyuwD9Pcnx T6+DY6mjmiu6wW2r3GJvfNTN3FunHmwSzXu7aY6/aLFvS22TTcpgHfZlU3aL7BlU lDuRsmhFZmSHqs7qWQwrkTf+2uCHijzjFbR3Tw7ebHpLJtf0qG12FTwrIKnUqOC2 Okj4AFGrDTG3Y348AiI66tmPksSW6FHAYmJpxc8GdU2O41VqAUzZaTNEZLh8MVas OaUpOhYmskrRWhBUhs7jE5NOZnwJUm3VPzU3zas4wijsHeVSWLa/i/6pSmi+HE9q 0WvUi0iOPqQWfykDY13Uw0nqIo1LEe8QRuFykABc8E9/L3l6P5Q= =RTuG -----END PGP SIGNATURE----- --Sig_/P5t9xemXHAgk_b6t2Sx4khH-- --===============0798456817== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs --===============0798456817==--