 |
|
|
|
|
|
|
|
|
|
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: heckling, x
music: reverend horton heat - bales of cocaine
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
So I had this code that did essentially:
for (int i = 0; i < num_files; i++)
if ((fd = open(files[i]->name, O_RDONLY)))
do_stuff(fd);
And I figured, hey, I've got an I/O scheduler and my disks have command queueing now, let's mitigate some of that seek death and do multiple stuffs in parallel. Well, here in ***america*** where fork() is cheap you'd do:
for (int i = 0; i < num_files; i++) {
if (num_kids == MAX_KIDS)
wait(NULL);
if ((fd = open(files[i]->name, O_RDONLY))) {
if (!fork()) {
do_stuff(fd);
} else {
num_kids++;
}
}
while (waitpid(-1, NULL, WNOHANG) > 0)
num_kids--;
}
while (num_kids--)
wait(NULL);
And then it's off to the bar. For some reason I thought that maybe doing it in pthreads would be a good exercise, and tried it that way first. (Actually I tried POSIX AIO zeroth. Ha! Good one, guys. You almost got me.) That went something like:
for (int i = 0; i < num_files; i++) {
if ((fd == open(files[i]->name, O_RDONLY)))
pthread_create(&thread[min_thread_index], NULL, do_stuff, (void *)fd);
/* hmm, how to throttle thread creation? */
pthread_join(&thread[i % MAX_KIDS], NULL); /* bonghits in the hood */
/* and then reset min_thread_index somehow? ugh */
}
Except that doesn't work, because you can only join with named threads, and not just whichever one happens to die first. I have no idea how long each of these threads is actually going to take, so round-robin is a waste of time. I could stick in a semaphore that every thread downs on init and ups on termination, and block the dispatch loop on that, but that's still not enough, since then I still need to figure out - somehow - which thread died so I can reuse its slot in thread[]. Why pthread_create() doesn't just return the new pthread_t is beyond me. Of course ideally we'd have waitfd() that was smart enough to cope with thread IDs too, and you'd message the thread ID back out to the master process somehow, and you'd still have to allocate your own pthread_t's anyway. Hooray for unix. Tags: fail, nerdery
music: nine inch nails - gave up
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There's a new kind of toy that keeps showing up at the office. Laptop vendors are really starting to push multiple-GPU machines. The theory goes that you can use one low-power GPU while you're on battery, and a high-performance GPU when you're plugged into wall power. I've played with a couple of these so far and people are starting to ask about them, so I figured I'd write down what I know and what I think the plans are. The best case is that you get a laptop like the Lenovo Thinkpad W500, where the BIOS has options controlling the GPU setup. You can pick GPU A, or GPU B, or switchable graphics. If you pick one or the other, that's all that will show up on the PCI bus, and so X will pick it up and run with it. Hooray! If you pick switchable graphics, we'll see two GPUs on the PCI bus. And now, things get tricky. Which one is active? Well, you could look at the VGA routing bits in the PCI configuration and attempt to figure out which GPU the BIOS enabled. But on the above-mentioned Lenovo, that doesn't work, VGA is just not routed anywhere. Maybe you could look to see whether only one device has memory and i/o decoding enabled, but again, that doesn't seem to be reliable, and what do you do if there's more than one? Ideally this is where ACPI would come to our rescue, and there'd be some platform method to call to tell us which ASIC to talk to. Maybe there is, but we haven't found it yet. Neither do we seem to get any unexpected ACPI events when switching from battery power to wall power. The Lenovo has an option in the BIOS that claims to automatically detect whether the OS supports GPU switching, but it doesn't seem to be reliable, in that if I turn detection on, I still see both chips on the PCI bus. Nonetheless this does indicate that there's some platform support there somewhere and we just need to look harder. Of course, if you're unlucky, you got a machine like the Sony Vaio Z540, where the BIOS has no GPU options, period. If you end up in a situation where you see two video devices on PCI, just write out a minimal xorg.conf that picks the driver and the PCI slot, and hopefully things will work. If not, you have two pieces, and you can keep them or not. Anyway, that gets you as far as doing the same boring single GPU stuff you've always done. As far as runtime switching goes, we're still pretty far off from making that a reality in the open drivers. We could hack up the relevant drivers such that we initialize them both but just only feed commands to one or the other, and then write the serialization exercise to move pixmaps and such from one to the other on switch events. Or, we might be able to start one X server on each GPU and then stick an Xdmx in front of them. In neither case will GLX work the way you expect (if at all), and there will be all kinds of fun corner cases trying to get the second chip to come up exactly compatibly with the first. Getting this to work well should actually be a lot of fun, and there's lots of opportunity to sweep away old bad design and come up with something good. In tangentially related news: my LCA talk was accepted! I'll be talking about shatter, which is a project to rewrite the X rendering layer to work around various hardware and coordinate limitations. This is not unrelated to the above problem, hopefully we'll get rendering abstracted far enough away from the driver to make it easier to switch among drivers at runtime. music: local h - michelle (again)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The Fedora 10 name elections are open. My totally awesome name suggestion for F9 (Bathysphere) lost by a slim margin, so now I'm lobbying harder for decent names. So here's what you should vote for: - Whiskey Run, because whiskey is awesome, and the potential for a whiskeyrunner theme in the artwork is excellent.
- Saltpetre, because it's a double-whammy connection with Sulphur (British variant spelling, and component of gunpowder), and gunpowder -> steampunk art -> awesome.
- Farnsworth, because Futurama.
- Cambridge, because Red Hat Linux 10 would have been Cambridge, and we finally made it to version 10 of something.
Every time you vote for something else, God detonates a kitten. Tags: fedora
music: dethklok - awaken
|
|
|
|
|
|
|
|
|
|
|
|
go back 
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
