activity wholist changelog info
now if you've got a pair of headphones...
you'd better get 'em on and get 'em cranked up
I'm currently fighting the Intel graphics driver on Ironlake (Core i3/i5/i7). It's nice that I have some documentation for it? Except that a typical page looks like this:

Strong work guys.

Tags: , ,
music: placebo - you don't care about us

pong! (x7) || ping?
I see Intel is continuing their excellent support story for Poulsbo.  I wonder just how much goodwill they're willing to lose over this chip.

Tags: ,
music: download - affirmed

pong! (x2) || ping?
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

pong! (x2) || ping?
I really am stunned that anyone thinks this is a worthwhile use of time.

Stunned is one word for it. Dismayed is another. Take your pick.

Tags: ,
music: rob zombie - dragula

pong! (x20) || ping?
I find it entirely appropriate that the ACPI name for the embedded controller in a Sony Vaio would be H8EC.

Tags: ,
music: junkie xl - more

pong! || ping?
Dear LG and/or Cingular:

The one app I want to use on my cell phone is Google Maps. The JVM on my cell phone has two settings for network access for applications, that I have to click through every time it does a connect():
  • Yes, always ask

  • No, never grant

Tags: ,
music: pitchshifter - genius

pong! (x6) || ping?
in OSX, command-m means minimize. your VPN client, on the other hand, means HOLY JESUS IT'S EATING MY EYES NNGNGHH SILLY RABBIT HIGS ARE FOR KIDS.

Tags: ,
state: hateful

pong! (x6) || ping?
I had nearly forgotten about this, so I want to get this written down before I forget it again.

Microsoft had a booth. They were demoing Vista. On a nice beefy laptop with a nVidia GeForce Go 6600. They had whatever they call the moderate bling level turned on, including the frosted glass effect in the titlebars and whatnot.


Over in the open source pavilion, we had compiz on an Intel 945GM cruising right along.

Draw your own conclusions.

music: orbital - funny break (one is enough)

Reason number 484 why you are Not Allowed to write your own hash functions. 1024 buckets and 780 are provably empty. Truly a work of art. Also note the log scale on the y axis.

Update: The new version is even worse. Proof left as an exercise for the reader.

music: outkast - prototype

pong! (x8) || ping?
ajax's rules of software success, #17: if Eugenia doesn't get it, you're probably doing something right.

state: amused
music: filter - gerbil

pong! (x16) || ping?