On Thu, 08 Apr 2021, Pekka Paalanen <ppaalanen@xxxxxxxxx> wrote: > On Thu, 08 Apr 2021 16:49:37 +0300 > Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> wrote: > >> Anyway, this is only tangentially related to the library. I just think >> we need to take DisplayID better into account also in the *users* of the >> library, as they shouldn't really even look at the EDID if the plain >> DisplayID is there, per E-DDC 1.3 section 3.1. > > That makes me wonder what the kernel DRM uAPI for getting a DisplayID > block into userspace would be. A new read-only KMS connector property? It's certainly a model everyone's used to working with. Is it worth coming up with something new when you anyway have to deal with the existing edid property for years to come? > Which means userspace (e.g. Weston) needs to know to read the new > property. If it does that, then it already knows that it should favour > DisplayID over EDID, and there is little the library could do to help > with that. Agreed. One of the problems for this uABI is that technically you're not supposed to read the EDID if the DisplayID is available. But the kernel needs to read both to expose both to userspace. I don't really see a way around that. The spec allows for leaving out EDID at 0x50 completely, which may eventually require updating kernel and userspace to be DisplayID aware. > Unless you think the library should be making DRM ioctls, which doesn't > sound good to me. Agreed, keep it simple. I'd say the library should probably stick to parsing an in-memory blob or fd passed to it, and focus on providing parsed information that's independent of the underlying data structure, whether it's DisplayID or EDID. Perhaps that should be the takeaway; try to minimize parsed data where the consumer needs to know whether it originated from DisplayID or EDID? BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
