activity wholist changelog info go back go back go forward go forward
now if you've got a pair of headphones... - A brief treatise on standards
you'd better get 'em on and get 'em cranked up
ajaxxx
ajaxxx
Add to Memories
Share
A brief treatise on standards
Monitor plug and play works by storing a descriptor called EDID in the monitor. The most important thing in this descriptor is the list of modes that the monitor supports. You would think this would be a fairly straightforward thing, but it's actually not, because you've only got 128 bytes to work with. So there end up being multiple ways to encode a mode in EDID:
  • the Established Timings fields I and II and Manufacturer's Timings, which is a three-byte bitmap of 17 industry-standard timings, plus seven bits of "manufacturer's mask" which could in principle be more modes but no manufacturer publishes what they mean
  • the Standard Timings field, which is an array of eight two-byte codes, thus: eight bits for width in multiples of 8 with 0x01 meaning 256; two bits for image aspect ratio (with one of the combinations overloaded to mean 16:10 or 1:1 depending on the spec revision); six bits for field refresh rate minus 60
  • Up to four of various 18-byte detailed monitor descriptors, including:
    • Detailed Timing descriptors, which encode more or less every timing parameter including sync intervals and polarity, borders, interlacing, stereo, star sign, etc.
    • Display Range Limit descriptors, which can describe sync range intervals and optionally mark them as supporting the GTF or CVT timing formulas, implying that any mode conforming to those sync ranges and timing formulas is supported
    • arrays of up to six Standard Timing identifiers, encoded as above
    • arrays of up to four 3-byte CVT descriptors, which encode twelve bits for image height, two bits for aspect ratio, a two-bit enum for preferred refresh rate, and a five-bit mask for supported refresh rates
    • the Established Timings III descriptor, which comprises 44 bits of yet more industry-standard timings as published in the DMT spec, and 52 unused bits set to zero
    • potentially any of sixteen manufacturer-specific detailed blocks, none of which are documented, any of which could contain mode support information
Not content with the restrictive expressive power of base EDID, an extension mechanism was introduced.  You can have up to 255 128-byte extension blocks, including:
  • the Consumer Electronics Association extension, which lets you specify:
    • Arbitrary numbers of Short Video Descriptors, which are one-byte indices into a list of timings in the CEA spec
    • Arbitrary numbers of detailed timing blocks, encoded as in base EDID
  • the Video Timing Block extension, which lets you specify:
    • Zero to six detailed timing blocks, encoded as in base EDID
    • Zero to forty CVT 3-byte descriptors, encoded almost as in base EDID except with fewer legal aspect ratios
    • Zero to sixty-one Standard Timing descriptors, encoded as in base EDID
  • the Device Information extension, which lets you specify:
    • A bit under the Miscellaneous Display Capabilities section for "VGA/DOS Legacy Timing Modes" support, which is a predefined set of 24 low-resolution modes you remember from EGA
  • Manufacturer-specific extension blocks, which are naturally undocumented and could contain timing info
Naturally, the display industry found this lack of flexibility entirely unacceptable.  So, soon and very soon, you will also begin to see displays that conform to the newer DisplayID specification.  Fortunately, to minimize time to market and maximize software reuse, DisplayID timing descriptors are entirely compatible with EDID:
  • Type I detailed timings, which are encoded exactly like the detailed timing descriptors in EDID, except for using an additional byte for pixel clock, moving the stereo and interlace bits, adding an aspect ratio field, eliminating borders, and widening the storage for all the horizontal and vertical timing numbers
  • Type II detailed timings, which are encoded exactly like the detailed timing descriptors in EDID, except for being only 11 bytes long, using an additional byte for pixel clock, moving the stereo and interlace bits, eliminating borders, storing all horizontal timing parameters in terms of eight-pixel character cells, and widening the storage for vertical timing numbers
  • Type III short timings, which encode CVT timings in three bytes exactly like CVT 3-byte descriptors in base EDID, but do it as a bit for preferred-timing-or-not, a bit for reduced-blanking-or-not, four bits for aspect ratio, eight bits for horizontal image size in eight-pixel character cells, a bit for interlaced-or-not, and seven bits for refresh rate
  • Type IV timing codes, which are one-byte indices into the DMT timing list, unlike any EDID encoding method
  • Supported VESA Timings data blocks, which is a ten-byte bitfield corresponding to various modes in DMT, but not in the order that they're in the DMT spec, nor in the same order as the Established Timings I through III in base EDID
  • Supported CEA Timings data blocks, which is a seven-byte bitfield corresponding (shockingly) to a superset of the CEA mode list in the most recent version of the spec I have handy, and even in the same order as in the spec
  • Display Range Limit descriptors, which are exactly like the encoding in base EDID, except for widening the storage for pixel clock, shrinking the storage for horizontal and vertical sync limits, adding maxima for horizontal and vertical blanking, and removing support for GTF
  • CEA-defined blocks, which are presumably in a newer version of the spec than I have
  • Manufacturer-specific data blocks
Did I say compatible?  That other thing.

So the other great part about DisplayID is that it requires host software updates to work, because - afaict - it's published at the same I2C address as EDID was.  This is kind of okay for laptops, since you know what software is shipping on them.  It's less okay for standalone displays, because now it raises the very real possibility of being able to buy a monitor that is too new to work with your old operating system.

Even better, drivers using VESA BIOS Extensions (which admittedly are kind of boned already) are about to be left out in the cold.  The VBE spec only defines a call to get EDID, and no legal DisplayID block can possibly be confused for an EDID block, so if your video BIOS actually checks for the EDID block header, there's no way to get it to return DisplayID anyway.  You now have a combination of video card, cable, and monitor, that can not be used together with VBE.  For people running the unfortunate sort of OS you have to pay for, there's the other kind of connector conspiracy too, where you probably can't get a combination of (native driver that supports DisplayID) and (operating system with native driver support) for your hardware either.

Thanks VESA.

Tags: ,
music: reverend horton heat - bales of cocaine

Comments
mjg59 From: mjg59 Date: June 22nd, 2009 10:00 pm (UTC) (link)
Thesa.
sneakums From: sneakums Date: June 22nd, 2009 10:03 pm (UTC) (link)
Tim Kreider said it: "the fuckers, O the fuckers".
pong! (x2) || ping?
$ ph
Adam Jackson
User: ajaxxx
Name: Adam Jackson
$ cat .plan
gpg: DD38 563A 8A82 2453 7D1F 90E4 5B8A 2D50 A0EC D0D3
$ nm -D
$ cal
Back November 2010
123456
78910111213
14151617181920
21222324252627
282930
page summary
tags