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

[Ser, Simon]

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.

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.

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