Notes on E-EDID and DisplayID support

[Adam Jackson]

I'm looking at adding E-EDID support to the server as part of a possible
feature for Fedora 10:

https://fedoraproject.org/wiki/Features/HDTVEnhancements

As a quick summary: EDID allows for "extension blocks", which are
additional data payload after the base block that describe additional
features of the display.  The HDMI spec requires at least one such
block, containing a descriptor identifying the device as HDMI,
documenting the audio capabilities and such.  This is specified as part
of the CEA extension block (the specification of which is not publicly
available, but I bought a copy of it a while ago), but there are other
extension block types.  Most of them are documented in VESA
specifications, which the Foundation has access to.

The E-EDID support in the server as it stands will fetch all available
EDID blocks, and makes them available internally in undecoded form.  We
also have a 'cooked' representation of the base block which is a bit
more pleasant to deal with.  It would be good to add a similar cooked
form for the extension blocks as well, and I intend to.

The problem is that the only sensible way to add that cooked form
essentially requires an API addition.  The xf86MonPtr type has no
destructor.  We could statically define a big union of cooked extension
blocks off the end of it, but a) you can have like 512 of them, and
their cooked forms are not small, b) that would break ABI as soon as one
of the extension specs was modified and we needed to cook more info out
of the raw form.  So you need to build a big tree of mallocs, but in the
absence of a dtor, you'd leak everywhere.

In practice I don't think this is a big deal.  Since there's no dtor as
it stands, all the drivers are at best just calling xfree() on the
xf86MonPtr, which means they're leaking the raw DDC block contained
within.  So we're leaking already; drivers that want to not leak, will
want to use this new API anyway.  But it's the sort of thing that
touches every video driver, so I figured it was worth announcing.

This will also get more complicated in the future.  Apparently
constructing a conformant (hah!) EDID block was just too much work for
some vendors, so there's a new spec called DisplayID from VESA that
we'll have to deal with at some point.  From what I've been able to
glean from the internet, it's a variable length format right from the
start, which means we probably won't be able to convert it to
cooked-EDID internally.  I'd know more, but I don't have the spec yet,
as I don't have the site access password for VESA.  I think Egbert does
though.

For DisplayID I think we'd be better off with a new query API that keeps
the internal representation away from the drivers.

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