Re: Call for an EDID parsing library

[Simon Ser <contact@emersion.fr>]

On Thursday, April 8th, 2021 at 5:28 PM, Jani Nikula <jani.nikula@linux.intel.com> wrote:

> On Thu, 08 Apr 2021, Simon Ser contact@emersion.fr wrote:
>
> > On Thursday, April 8th, 2021 at 4:58 PM, Jani Nikula jani.nikula@linux.intel.com wrote:
> >
> > > Perhaps that should be the takeaway; try to minimize parsed data
> > > where the consumer needs to know whether it originated from DisplayID or
> > > EDID?
> >
> > So an EDID/DisplayID abstraction layer?
> >
> > It sounds like only an EDID and DisplayID expert could come up with a
> > sane API for that. Also some metadata will only be available in one
> > format and not the other.
>
> Well, some of the data already comes from DisplayID extensions in the
> EDID.
>
> My point is, if you parse displayid and edid into different structures
> and APIs, what will the code bases using the library end up looking
> like? Not pretty? Implementing the same conditionals all over the place?
> Anyway. I feel like I'm derailing this a bit, and I really don't want
> that to happen. I think DisplayID is a consideration that should not be
> forgotten, but it's probably not the first priority here.

I agree with the goal. I'm just saying that it considerably increases
the complexity of the task.

If you're just doing an EDID library, you can just expose the EDID
specific bits with a sane API. If you're designing an abstraction
layer, you need to have a good look at both APIs, try to come up with
common data structures that fit both, and be aware of the upcoming spec
changes to not be stuck with a bad API.