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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
