Call for an EDID parsing library

[Jani Nikula]

On Wed, 07 Apr 2021, Hans Verkuil <hverkuil at xs4all.nl> wrote:
> On 07/04/2021 12:31, Jani Nikula wrote:
>> On Wed, 07 Apr 2021, Hans Verkuil <hverkuil at xs4all.nl> wrote:
>>> It is the most complete EDID parser I know based on the various standards.
>> 
>> Does it support pure DisplayID in addition to DisplayID blocks embedded
>> to EDID extension blocks? I think we'll be needing that sometime in the
>> near future. (We don't yet support that in the kernel either.)
>
> It doesn't, but that shouldn't be too hard to implement.
>
> Do you have examples of that? If I had some, then I could implement support
> for it in edid-decode.

Alas, I don't. We don't come across them naturally, because the kernel
does not follow VESA E-DDC 1.3 to read 0x52 address to read the plain
DisplayID. I guess it's also common to add DisplayID 2.0 data blocks in
EDID extensions (and I see that edid-decode handles them), though this
is not described in DisplayID 2.0 spec the way it is in older DisplayID
specs.

The differences aren't that big, really. Slightly different constraints
on the block size when they're not embedded in EDID, as well as
different mandatory blocks.

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.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center