small EDID library (possible start)

[Kai-Uwe Behrmann]

Am 06.01.10, 10:38 -0500 schrieb Adam Jackson:
> On Wed, 2010-01-06 at 11:13 +0100, Kai-Uwe Behrmann wrote:

>> Soren Sandmann is mentioned as the author of edid-parse.c (2007). I took

Ah

> edid-parse.c is part of libgnome-desktop.  It's not used in the server
> at all.

>> The attached oyranos_edid_parse code is my try on a API. It provides a
>> very simple interface. EDID is passed as a void* pointer. Results are
>> returned in a flat structure array. The results are a kind of key value
>> pairs. The core API consists of only three functions. The returned values
>> are referenced by a key name.
>> Additionally a XEdid_s structure is declared only for further parsing
>> convinience. The parsed items are merely colorimetric and identification
>> parts. Missed is the timing and the resolution stuff, which can be added
>> later.
>
> I'd actually started down these lines shortly after this year's XDC in
> Portland, so, thank you for reminding me!  The EDID interpretation code
> in the server is one of the last remaining targets for things to strip
> out of the server and reuse elsewhere, so I started hacking up a library
> that would be plausibly good enough to be used from both X and
> libgnome-desktop.  Currently it looks like this:
>
> http://cgit.freedesktop.org/~ajax/libminitru/

... currently the monitor modes parsing.

> As far as API design goes, X's internal API is pretty entirely wrong.  I
> don't see any value in storing any unpacked representation of the EDID
> block internally to the library, it's just wasted memory given how
> trivial it is to unpack on the fly.  You also really really need to

The key/value API fits relatively well the Oyranos data handling model. So 
that shurely lead me in the first place. Oyranos is designed towards 
being as generic as possible and as specific as needed.

But as it is Xorg code I have no deeper opinion and can follow your 
design.

> parse extension blocks, and you need to be able to handle display
> information data that isn't EDID.

agreed

> So I think the API we want is less about querying for specific fields of
> the EDID, but about asking questions and getting answers (which may be
> "I don't know, the device doesn't specify").  X wants to ask questions
> like "what is the list of supported modes" and "would this mode work if
> I tried it".  I imagine Oyranos wants to ask questions like "what's the
> white point" and "what's the gamma curve look like".

As long as the answers do not change between releases, thats all fine.
... and EDID is still available as a last means.

> Your XEDID API doesn't do this.  It hands back a list of key/values, but
> then the application still has to know how to interpret them; _each_
> application has to know how to interpret them.

The keys/values are used currently to generate ICC profiles for monitors 
and to identify the monitor devices. So at least for Oyranos that kind of 
works and as far as I can see, there is not much further code needed.


kind regards
Kai-Uwe Behrmann
-- 
developing for colour management 
www.behrmann.name + www.oyranos.org