[igt-dev] [PATCH i-g-t v2] lib/igt_edid: new library for generating EDIDs

[Jani Nikula]

On Tue, 16 Apr 2019, "Ser, Simon" <simon.ser at intel.com> wrote:
> On Tue, 2019-04-16 at 14:05 +0300, Jani Nikula wrote:
>> > > Do you already have some thoughts on how we want to solve handling the
>> > > extensions blocks?
>> > 
>> > I've already started to work on this. I think callers should allocate a
>> > large enough buffer, e.g.:
>> > 
>> >   char buf[sizeof(struct edid) + 2*sizeof(struct edid_ext)];
>> > 
>> > (Extension blocks have a fixed size)
>> > 
>> > And then should map a struct edid to it:
>> > 
>> >   struct edid *edid = (struct edid *) buf;
>> > 
>> > The annoying thing is that the number of extensions at the end of the
>> > EDID block isn't fixed. We could add a new field at the end of struct
>> > edid:
>> > 
>> >   struct edid {
>> >     …
>> >     struct edid_ext extensions[];
>> >   };
>> > 
>> > So that callers can do this:
>> > 
>> >   struct edid_ext *ext1 = edid->extensions[0];
>> >   struct edid_ext *ext2 = edid->extensions[1];
>> > 
>> > Another annoying thing is that extensions can themselves contain
>> > multiple sub-blocks of different sizes… For now I've opted for a char
>> > buffer that can be casted into sub-blocks. This isn't the best solution
>> > ever, but I haven't found a better design yet. Let's discuss about this
>> > in the next patch. :)
>> 
>> While it's easy to write something that's better than what we currently
>> have, as you see this gets complicated more quickly than you'd like,
>> especially working in C. We're not the only ones needing EDID
>> generation, so I'd suggest looking at what others are doing before
>> embarking on writing a full blown generator. See e.g. [1].
>> 
>> [1] http://mid.mail-archive.com/20181121133624.i4vxgt7atnv3ads6@sirius.home.kraxel.org
>
> Thanks for the link! I can't find other EDID generators written in C,
> it seems most people focus on parsing (and most people = a few…).
>
> Here is the code for reference: [1].
>
> It's really too simple for us. It takes the output identifier, the DPI
> and the resolution and generates an EDID from that. It also operates on
> a raw `char *` buffer which makes getting the indexes right tricky. All
> in all, not a lot we can learn from.

Fair enough, thanks for looking into it.

> FWIW, I've been thnking about a possible "libedid" for a while. Many
> projects need to parse/format EDIDs and it's a little unfortunate that
> we need to duplicate code (especially when parsing also involves
> applying quirks). See [2] for a discussion about this.

For starters I think a libedid could start within igt, as long as you
make sure it remains independent of the rampant igt-isms.

BR,
Jani.


>
> [1]: https://github.com/qemu/qemu/blob/master/hw/display/edid-generate.c
> [2]: https://marc.info/?t=154555671400001&r=1&w=2

-- 
Jani Nikula, Intel Open Source Graphics Center