For the past several days, my free time has been occupied with only a few things: restructuring the Arch Linux wiki’s Poulsbo article, enjoying rather delicious vegan “Sloppy Joes”, and wrestling with the ancient “PSB” binary blob driver. Today I’m just dumping a few things I’ve figured out about it.
First thing is about why I can’t get the accelerated video playback, via VA-API, to work. libva, which is responsible for allowing such things as mplayer-vaapi to use the PSB driver’s capability to access the GMA500’s H.264 acceleration abilities, looks for something called “psb_drv_video.so”. With the current PKGBUILDs in the Arch User Repository, this file is installed, under
but libva is configured to look for it in
So, after copying that over to where its expected to be found, you’d expect everything to work, right? Nope.
libva: libva version 0.31.1
libva: va_getDriverName() returns 0
libva: Trying to open /usr/lib/dri/psb_drv_video.so
libva: error: /usr/lib/dri/psb_drv_video.so has no function __vaDriverInit_0_31
libva: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit
Looks like Arch’s current version of libva is looking for something that didn’t need to exist back when the binaries were made. And, although the open-source parts of the driver have been patched to work with Xserver 1.7 and newer, this can’t be done with psb_drv_video.so because it’s a BLOB. 😡 So, no mplayer -vo vaapi -va vaapi
Second issue is similar: I couldn’t get XV accelerated video to work. Mplayer either complains that it can’t find an XVideo-capable card or some-such, or a window is drawn for Mplayer — and the Xserver completely locks up, except for the mouse. Progress?
The reason, according to the GMA500 wiki, is because that capability is handled by another blob: Xpsb.so. So, no mplayer -vo xv. 😡
The third issue is due to both blobs depending on a modified libdrm 2.3.0 — while Arch Linux’s Mesa OpenGL implementation is compiled against libdrm 2.4.something. I’ve tried compiling a similarly-patched libdrm 2.3.4 from the tarball in the Ubuntu gma500 PPA, but that didn’t create drm-psb.ko — which is rather necessary for everything to work.
So, pros and cons of using the PSB blob with Arch Linux:
- Can use current kernel (2.6.35-ARCH)
- Can use current Xorg-server (1.8.1.something)
- Full, native resolution
- Backlight control (see my how-to on this)
- No VA-API acceleration
- No XVideo acceleration (and quite likely will lock up your Xserver — won’t even be able to switch to a terminal)
- No OpenGL/Mesa ANYTHING.
At least with the FBDEV driver I can try some software raster whatchamacallit for OpenGL. (Yes, that is indeed a word — I misspelled it and Firefox corrected me. :P) The backlight control, however, is more important to me. And I can’t run Xorg with the FBDEV or VESA driver over a PSB-module-set framebuffer, either — it crashes with a static underline cursor with the former and distorts and repeats everything with the latter.
My next attempt will be to use the procedure normally reserved for IEGD driver experimentation to downgrade to Xorg-server 1.6, and try again with the PSB driver. 1.6 was the latest server version that worked completely, I think . . . if the video works then, I’ll try building whatever version of Mesa was current back when libdrm 2.3 was. I think that was 7.0.4, but I could be wrong, and that’s not even in the Mesa repositories anymore. I have to go on Sourceforge for it, and would have to heavily modify the PKGBUILD. *sigh*
Or I could just use Jolicloud — but then I’d have a LOT of hacking-away to do.
Or I could use Ubuntu 10.04 — but then I’d still have a lot of hacking-away to do.
Thus the headaches.
Thank you so much, Intel, for licensing Imagination Technologies’ PowerVR SGX 535 to use in your System Controller Hub series. >_< At least Nvidia keeps their blobs current.