small EDID library (possible start)

[Adam Jackson]

On Wed, 2010-01-06 at 11:13 +0100, Kai-Uwe Behrmann wrote:

> That is Adam Jackson's parse-edid.c with lots of global variables and no 
> library interface at all (2009). That is fine for the intented usage as 
> command line tool, but unfortunedly not a comfortable base for a library.

Yeah, that's really intended to be a conformance tester, not a general
purpose tool.

> Soren Sandmann is mentioned as the author of edid-parse.c (2007). I took 
> some pices from that. I like the returned structure at a first glace very 
> much. Unfortunedly the returned structure is quite static. So I was 
> unshure whether this will be extensible as library. I think this code is 
> used internally of Xorg for EDID parsing. The API appears to be visible 
> only to the server and is not exported. Please correct me if I am wrong.

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/

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
parse extension blocks, and you need to be able to handle display
information data that isn't EDID.

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".

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.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20100106/d0416e22/attachment.pgp>