Call for an EDID parsing library

[Jani Nikula]

On Thu, 08 Apr 2021, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Thu, 08 Apr 2021 16:49:37 +0300
> Jani Nikula <jani.nikula at linux.intel.com> 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