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 – 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 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, 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 so distributions can make it just work and everyone will be happy. Thanks.

61 Responses

  1. Taljurf » Poulsbo updates … for those who don’t know

    […] , I’m always after any news about poulsbo drivers. First of all, many of us know why we are “screwed” , so (until lately) we had no choice except to use proprietary drivers which Adam Williamson made […]

  2. some1 in need of intel dr lol
    some1 in need of intel dr lol December 8, 2014 at 11:19 am | | Reply

    For the so-called “win”, meaning, the internet safety wise looser type of systems, any software or drivers are NO problem to install – downside of win: no net security, as said.

    BIG downside of Linux nevertheless: Drivers and programs can be a pain in the u know what to either install or uninstall. Sure, most programs and scenarios work, nowadays, in mostly Linux Mint, where on my newer Lap, the graph driver installation didn’t f… up my system, which did happen on lubuntu, when I tried doing lubuntu, before, directly on the lap, which I can not recommend, for the simple and correct graph driver installation from within the graphical operating system surface, brings the Lubuntu user to a dos screen after reboot — not so Linux Mint, which survives a graph driver installation. Mint is also stabler in terms of a stable Startmenu and Panel, than let’s say this not so really funny LXLE. But now, also the LXDE Mint has issues which the simple Menulibre. Do never install Alacarte on Mint, or, it can only change entires, not make new ones. I did not even find any good menu editor for Linux (Mint) until now, since now two years Mint usage of mine.

    Also, on my slower, older Lap, I now see, I have to on Linux, try that GMA500 unofficial repo, which gives a 404 not found error when adding the repo correctly. I gotta go with alternative drivers — Intel says, it only supports GMA500 on Fedora.

    I tried anyway compiling the debian and other sources from their driver on Mint, Mint is not gonna fall down so easily as in a broken installation, and if so, no prob, I do it from fresh.

    What is less funny, even, is to see, that Intel cares a u know what about old HW they did. They gotta … step onward, you know, so could we hear them say or think. But, I bought a lap, and I deserve support of the hardware, as in software-drivers for that hardware. So does every buyer of hardware. I do not need fancy new whatnot, I want to use my old hw.

    The problem is, that dominating companies are less under pressure than many others. When I read Intel’s legal introductory text to that driver, it really reads like one big “user go to h…”, in fact: “Intel is not reponsible for the functioning, nor for the efficiency of this software…” and so on. This is not what I expect from any hardware manufacturer that has a duty to give out drivers. I am sure not personallz or even any emotionally upset to the disfavor of Intel. Really not. Seriously. I do not even any dislike intel. And I DO dislike many other big companies. I still like Intel, but this here, this driver story, for a bit older graph hw of intel, ah no, please.

    And please, I do not subscribe to this site and place here, so please, do not answer to this post.

Leave a Reply

Your email address will not be published. Required fields are marked *