January 30th, 2009
Intel GMA 500 (Poulsbo) graphics on Linux: a precise and comprehensive summary as to why you’re screwed
So, poking around idly on Google this morning, I came across the interesting fact that there is, in fact, a native Linux driver for Intel GMA 500 – Poulsbo – graphics on Linux.
Don’t get excited, though. It’s not like it’s actually any use.
That was the summary. Here’s the gory details…
As I wrote in my previous post, the GMA 500 is not really a follow up to all the previous Intel chips. It’s a bit of Intel’s platform with a PowerVR (those of you who’ve been breaking crap as long as I have may remember PowerVR as an early contender to 3DFX and NVIDIA; they’ve since scurried off into niche markets) chip slapped on top of it. So it’s basically a whole new architecture that needs a whole new driver.
Aside from the Vaio P and a couple of other systems, there’s one significant machine with the GMA 500 chip in it: the Dell Mini 12. Why’s it significant? Because Dell ship it with Ubuntu.
So, yes, there’s a native driver. Intel, Dell or some combination of the two contracted out to Tungsten Graphics to write a driver for it. This is presumably because Tungsten have been supporting PowerVR chips for a long time, so they know their way around the hardware. So, the driver was written, and included in the special-sauce version of Ubuntu that Dell uses, and also in Ubuntu Netbook Remix. It was even developed under the auspices of the Moblin project at first, and you can find the code in Moblin git – X.org driver, kernel module. Where it hasn’t been touched for eight months.
This is the first clue that all is not well. Up to that point it all looks fairly straightforward, but after that it rapidly goes to the dogs.
Trying to get the thing to work on a modern distribution, the first thing you notice is that it’s messy code. The kernel driver consists of a copy of about half of drm, with all sorts of stuff included and built that doesn’t really need to be. And it’s not remotely in sync with current drm. All it really ought to be is a few files which should have rapidly been merged into Mesa upstream. There’s even a comment in the code that shows the authors are aware of this, saying that one fairly trivial change should be done before the code is contributed upstream. But the change hasn’t been done to any Tungsten-, Dell-, Intel- or Ubuntu-sourced version of the code I can find, so it’s still a mess languishing in its own repository.
The second thing you notice is it doesn’t build with any kernel post-2.6.24, due to that issue and a couple of others.
The third thing you notice, if you’re lucky, is that it’s not even really the latest version of the code, and this is where things get really odd. As I mentioned, the copies of both the X driver and kernel module in moblin.org git have not been touched for eight months. However, squirrelled away in dank corners of the Ubuntu empire, you’ll find rather later versions of the code. It has eventually been figured out that the latest version of the X driver code is this one, if you combine the ‘upstream’ tarball (which is not, in fact, available anywhere ‘upstream’ that anyone I know of can find) and Ubuntu patch in that directory. The latest version of the kernel module code is stuffed in Ubuntu’s Miscellaneous Kernel Modules tarball – this one.
The further you dive down the rabbit hole, the odder things get. The X driver seems to depend on a proprietary firmware file, called msvdx_fw.bin, for…something. Apparently it’s needed for 3D acceleration and video playback acceleration to work. You can download this file from a post in an extensive and frequently messy and/or downright ill-informed Ubuntu forum thread on the topic. And, as far as I can tell, nowhere else. It also seems to depend on a supplementary X driver, Xpsb, for the same things – without both the firmware and Xpsb, 2D video playback acceleration and 3D acceleration don’t work. I don’t know where the heck you find that. The source trees definitely don’t build it.
Some of this is documented – in passing, seemingly more as an example case than anything else – here. A page that’s just sort of lying in the Ubuntu Wiki. Again, I only found it through the giant forum thread. The associated Launchpad project is listed as ‘Approved’, since May 2007, but ‘Not started’. With no other information.
So, anyway. I picked my way through this bizarre minefield and then tried to get the fricking thing to work.
First I hacked up a patch for the kernel module myself to make it build, not really knowing what I was doing. But it seems to more or less work. When it loads, it gives me a native resolution framebuffer. Out of interest, trying to start X with the fbdev driver at this point gets started and shows the grey dithered “X is starting up now” screen, but then hangs the system with caps lock and scroll lock lights flashing. Interesting result, but not what I was really looking at anyway.
Later on, while trying in vain to find some combination that would work, I found that Olivier Blin of Mandriva has been poking at this stuff, as he has a cleaner patch to make it build against 2.6.27 in his personal scratch directory: here. So I tried building with that patch instead of my own hack. They seem to work about the same.
Then I poked about at the X driver. It expects to build against various headers from the version of drm in the kernel module source, not the system copies (or at least not the system copies on Fedora 10). It also expects a particular xf86mm.h, which I pulled out of the relevant Ubuntu libdrm-dev package – so already having to hack stuff up here. With that and a few other minor tweaks, I got it to build.
But…yeah, it doesn’t work. With the newer version of the X driver from Ubuntu, it fails with a “could not mmap framebuffer (invalid argument)” error, almost immediately on trying to start X. With the older version from Moblin git, it just freezes on X startup. The system’s still running – I can power it off clean with the power button, it shuts down properly – but X doesn’t start and I can’t see a console either. There’s just a text cursor frozen at the top left of the screen. The last lines in Xorg.0.log are:
(II) Primary Device is: PCI 00@00:02:0
(WW) Falling back to old probe method for psb
(II) Debug: psbProbe
Okay, so after a whole day spent bashing around at this crap, I can very confidently and conclusively say, it’s utterly broken. By the looks of it, you can get it up and running, with a bit of futzing around, either by running Ubuntu Netbook Remix or running Ubuntu Hardy and forcing the Netbook Remix packages onto it – see the forum thread for details on that. But with any modern distro, it just doesn’t look like it’s going to work.
This is really silly, because the code is obviously 99% basically there and working. It just needs the people who actually know the code and the hardware to put it in the right places and not random obscure undocumented repositories, submit it upstream, and keep it up to date. But because, for whatever reason, the Intel, Tungsten, Dell and Ubuntu folks can’t get their fingers out of their asses and actually provide the code in a sensible, sane and open way, few people even know it exists, no-one’s seemingly working to keep it going with newer kernels, X.org and libdrm, and no-one has a freaking clue how to use it. And every Linux user with this chipset is getting screwed.
It’s not good enough, guys. Just get together, fix the freaking code, and get it in the kernel and X.org so distributions can make it just work and everyone will be happy. Thanks.