On Wed, 07 Apr 2021, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > On 07/04/2021 12:31, Jani Nikula wrote: >> On Wed, 07 Apr 2021, Hans Verkuil <hverkuil@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
