now if you've got a pair of headphones...

On Portland

2009-09-30T17:07:35Z

The Portland State University machine room - host of annarchy, aka people.freedesktop.org and the storage for personal git repos - had a rather catastrophic series of power failures yesterday. As in, both of the independent, UPS-backed power rails to the room failed simultaneously, multiple times. As best we can tell, one of those failures was during ext3 journal recovery of /home from one of the previous failures. fsck was utterly, utterly unable to cope with this.

So, /home got a reformat. /home on that machine was not backed up (and never has been advertised as permanent storage), so anything you had there is lost. Git repos can be restored from your own clones, of course.

the platform of choice for linux and open source

2009-08-07T18:40:30Z

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.

A brief treatise on standards

2009-06-22T20:05:37Z

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.

burn like an animal

2009-04-06T21:32:54Z

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.

consume until you bleed

2009-03-15T22:32:28Z

I've been poking at (tearing my hair out over) DisplayPort support for the various graphics chips under Linux. Rather than post something here that would soon be out of date, I made a status page on the wiki. The executive summary right now is No It Doesn't Work, but that should change soon.

DP actually promises to be a pretty cool technology. Compared to DVI it seems a bit overengineered, but that's sort of like comparing a car to a skateboard. Given the per-port licensing tax on HDMI, I think DP's eventual dominance is inevitable, but HDMI is pretty entrenched so that won't be any time soon. We'll just have to deal with the connector conspiracy until HDMI dies.

a sense of time

2008-11-22T22:29:28Z

I realized while at the show last night that I've been going to see Local H perform for over ten years.

No real story there or anything, but it was kind of pleasant to note, given how my life feels like it tends towards the transient. Four years is an eternity. Ten is incomprehensible. Maybe some things last after all.

wtf pthreads

2008-11-17T14:55:02Z

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.

pac-man is loving it

2008-10-17T02:56:11Z

I find it entirely appropriate that the ACPI name for the embedded controller in a Sony Vaio would be H8EC.

switching graphics argh

2008-10-06T21:24:32Z

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.

Words, words, words

2008-07-23T14:34:49Z

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.

mqp

2008-07-03T13:32:13Z

<airlied> is a blur-facist, someone who doesn't like Damon Albarn, or someone who thinks Damon Albarn is the new Hitler..

perhaps bonghits will fix my cell phone

2008-06-24T14:24:54Z

The Symbian Foundation: Because you didn't have enough bad free software already.

counterintuitive nipples

2008-06-22T15:40:46Z

I tire of people objecting to using git on the basis of bad documentation and UI obscurity. There seems to be a common blind spot here, which is that CVS (which everyone learned first) is just as bad, if not worse. The CVS manual has been getting steadily worse over time, and I challenge anyone reading about cvs up -j for the first time to correctly explain it, let alone sticky tags or binary file handling.

More fundamentally, I think people forget that source control is a very weird and very hard problem. Much like the lower levels of particle physics, you kind of have to implement the behaviour you expect using a model that's not intuitive. That the doc writers for git seem to revel in spewing nerdporn words like "tree-ish" at you is unfortunate, but people like seeing dmesg spew at boot for the same reason: it's obscure and therefore makes you feel cool.

Of course, no one needs to know how pretty much any vcs works under the skin on a daily basis, and that's why sensible git documentation exists. HELLO PEOPLE THE INTERNET HAS SEARCH NOW.

the reg: let's make shit up and pretend we're journalists

2008-04-17T19:33:13Z

Not, of course, that anyone should mistake The Register for journalism, but the article on Red Hat's desktop strategy is right about 580 nm on the "yellow" scale. For those of you not keeping score, we haven't released anything that could be called consumer desktop product in over five years. If this counts as "scurrying away" from a market, I wonder how they feel about the rapid decline of OS/2 in recent years.

not a substitute for sleep

2008-04-14T23:24:16Z

I came into the office this morning and wrote four things on the whiteboard. By the end of the day I'd crossed three things off. I could use more days like today.

Going to see Autechre with kernelslacker in about an hour. Woot! Then tomorrow, I leave for XDC2008. I'm not on the schedule this year, mostly because I don't have a lot to talk about. I expect I'll lead an ad-hoc session at some point whinging about releasing and integration and other such boring things. Last XDS featured lots of talk about things ahead, and right now we seem to be well in the middle of getting things done. Which is a pleasant problem to have, all things considered.

Also, I don't fly out of SFO until like 10:30pm on Saturday. Bay area people, you are hereby required to entertain me.

freenode: irc for idiots

2008-03-05T16:11:34Z

To whoever made it so you can't /nick when you're in a channel you can't send to: please die in a chemical fire.

braindrizzle

2008-02-29T16:52:17Z

yeah, we'll get right on that.

budget.com.au is made of fail

2008-02-03T00:47:53Z

1. Enter nationality.
2. Enter rental period and locations.
3. Select desired vehicle.
4. -ETIMEDOUT.

HELLO I HAVE MONEY I WANT TO GIVE YOU. PLEASE HELP ME GIVE YOU MONEY.

But no, these guys are novices:

Give up. Find another industry. Software is clearly not for you.

that's why the suicide machine is built for two

2008-01-25T16:10:04Z

Going to LCA in about seven hours. I absolutely did not lose the code I came in on a weekend to write three days before my flight, forcing a mad rewrite the day before. Nope. Nothing like that ever happens to me.

Fortunately what I've got now looks like it might actually work, and there's enough left to do to keep me occupied on the plane ride. Personal note to Australia: I don't know if this relationship can work. You always seem so distant.

After that I will be heroically uncommunicative, as I take a well deserved vacation. Then, most likely, I get to come back and wrangle both the Fedora 9 X integration, as well as Xorg 7.4. In lieu of postcards, please send your well-wishes written on the label of a bottle of tequila.

breaking the law to make your life harder

2007-12-17T14:14:31Z

At about 1700 last night I went out to shovel snow. This hadn't been done since at least Saturday, and it was raining for most of Sunday, so I had a good five inches of heavy wet snow to move. Took about ninety minutes, all told.

Except then later, at about 2200, I tried to take the trash out to the curb, and noticed that not only had the plows decided to run again, thus dumping about a ton of ice at the end of the driveway, but it had piled up so high that it crested over the snow pile on the curb, dumping another ton of ice on the sidewalk.

My back is rather sore this morning.

Your moment of pie

2007-11-20T22:40:00Z

Dual 30" monitors, lit by open source drivers. Note the remote debugging rig, which we used to get this working.

Happy Thanksgiving all. Go home, eat pie.

ajaxxx @ 2007-08-24T20:24:00

2007-08-25T00:25:01Z

View Poll: #1044751

Worst "Dear Lazyweb" ever

2007-08-01T22:04:25Z

I'm trying really hard to find a monitor with DPVL support, because I'd like to implement support for it in X. And failing. It seems no one wants to tell you the features that their hardware implements, because they don't want you to actually buy the thing based on what it can do. That, or it's just not implemented yet.

Is there actually a monitor out there that can do this?

There's also the semi-lazy way of discovering what devices have this, by implementing enough of the other VESA discovery specs so that I can read the appropriate bits out of the hardware, dump them in the X log, and then wait for google to index them. Which I'm sure I'll get to eventually, but there's less instant gratification that way.

guadec: an epitaph

2007-07-29T02:44:07Z

We failed to sell Jono's backpack on eBay (without his knowledge, let alone consent) from the pub because we couldn't get any semblance of functional internet (despite more than one person with a Bluetooth+GPRS/EDGE phone and an N800). This is not the flying car future I was promised, dammit.

But at least there was Pimm's.

My talk went okay I guess? Most of the people attending it seemed to be way high above the toolkit layer I was hoping for, so there was less feedback than I was hoping for. However, fooishbar did a similar talk on Saturday that was attended by the right set of people. So now we have more stuff to do. Yay!

Flying back to the states was less eventful than flying out, no delays or anything. Going through security three times was pretty awesome (wait, no). Heathrow wasn't bad so much as dated; it's impressive how much traffic they handle given how crap their layout and checkin process are. However they don't tell you your gate until 45 minutes before the flight departs, and - like every place else in the UK - the bagels aren't toasted.

Note for the future: try to live in a country with a less crap currency, lest you leave it for a week and come back a broke-ass ho.

Guadec, day 3

2007-07-17T22:00:01Z

<mjg59> i can't believe he's never been deported

(updated to fix markup. apparently lj's mobile UI doesn't escape html for you. i shouldn't be surprised.)