Re: Call for an EDID parsing library

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 08 Apr 2021, Simon Ser <contact@xxxxxxxxxxx> wrote:
> On Thursday, April 8th, 2021 at 4:58 PM, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> 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.


BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux