So, yes – today I successfully got the ‘psb’ driver from the Ubuntu Mobile repositories built and working on Fedora 10, with my Sony Vaio P.

Some new packages showed up in the Ubuntu repositories this morning, newer versions built for 9.04. So I thought I’d give it another shot on Fedora. And, with a bit of fiddling, it works. The packages build on Rawhide, too, so it should also work on Fedora 11, but I haven’t tested that yet. (I doubt video and 3D acceleration can work, as the proprietary Xpsb lump, which is some pre-built modules for X, hasn’t been released for Ubuntu 9.04 yet – it’s still only for 8.10, which is an older X server version).

And here’s binary packages, for Fedora 10 fully updated with kernel 2.6.27.21-170.2.56.fc10.i586 (you’ll have to rebuild the psb-kmod .src.rpm for any other kernel, I can’t figure out how to make it spit out an akmod package):

You need to download and install them all together. I haven’t bothered building a dependency chain between them or creating a metapackage to require them all, yet. It’s a bit rough and ready.

So far, 3D acceleration doesn’t work – I think because I’m missing some kind of janky rebuilt version of the Mesa DRI libraries that’s in the Ubuntu repositories. 2D video playback acceleration should be working, but I haven’t yet built the special version of mplayer that’s needed to test that. I’ll take a shot at those two (and some tidying up) tomorrow. If you’re interested, here is the Mesa DRI library stuff, and here is the patched mplayer (take note of the requirements at the bottom).

To get it going, you need to load psb on boot – it doesn’t come with any modaliases (sigh), so it doesn’t get automatically loaded – just stick ‘modprobe psb’ in /etc/rc.local . Then you need a /etc/X11/xorg.conf which specifies psb as the required driver. That should be all. UNLESS you have a Vaio P, at least by my experience. X will fail to start, with a strange error in Xorg.0.log: “could not mmap framebuffer…(operation not permitted)”. There’s another error in /var/log/messages – something like “program xorg tried to access /dev/mem between foo and bar”. The workaround for this took a bit of lateral thinking – it’s something to do with memory mapping, so…futz with the memory. Turns out that pretending you have 512MB, 1GB or 1.5GB of RAM makes it work (haven’t tried higher than that yet – the P actually has 2GB). So just add:

mem=1500MB

as a kernel parameter. And then you should be good to go.

One thing I found impressive is that the driver actually has a rather good RandR implementation. It has the no-dynamic-framebuffer-resizing limitation, so you need to add a Screen section to xorg.conf something like this:

but once you have that, the chip is capable of driving my setup – the P’s internal 1600×768 display, and an external 20″, 1680×1050 display – side-by-side (since it’s RandR 1.2+ stuff, you can configure it with gnome-display-properties). Pretty neat. It even seems to have some level of hotplugging – when I unplugged the external display, it automatically resized everything down to the internal display, without even needing to do xrandr –auto. Nice.

This should be *fairly* easy to adapt to other distros from my .src.rpm’s, I might try and throw together Mandriva packages this weekend if I get time (have to turn the kmod package into a DKMS package). But, of course, it’s not fully F/OSS, not suitable for inclusion in the repos for F/OSS distros. Let me know how you get on with this stuff in the comments.

it’s basically, as far as anyone can tell, the repository for stuff that winds up in the custom builds of Ubuntu that ship with Dell systems. Canonical, Dell and Intel are all very quiet about it. For reference, these bits are open source and the source is in the tarballs in that repository: libdrm-poulsbo, psb-kmod, xorg-x11-drv-psb . psb-firmware and xpsb-glx are proprietary lumps – the ‘source’ tarballs contain a firmware lump and several prebuilt libraries / X.org drivers (respectively), the packaging consists solely of dumping them into the appropriate location. The license on them specifically forbids modification, including reverse engineering (I’m not sure whether that would stand up in court).

Gave up on solving the rpmfusion dependencies and compiled psb-kernel-source-4.40 manually with “make DRM_MODULES=psb”.

Merely inserting psb.ko kills the text console (screen goes black with green garbage at the top). Is this normal ?

X is terminated by oom-killer on startup, after mmap’ing a total of 45 MB from /dev/dri/card0 (according to strace).

“Program X tried to access /dev/mem between 7f6a3000->7fea4000” seems to be triggered by CONFIG_STRICT_DEVMEM and xf86MapVidMem(). This is puzzling – how do all the other drivers with “stolen” video memory avoid this ?

So, still no luck for me, but thanks for all your work. After trying to match gregkh’s staging drm driver with the Ubuntu 8.10 sources I can appreciate the effort. Maybe I will downgrade to 2.6.27 later.

No, here it just gives me a native resolution (think tiny!) framebuffer console. Did you load both the psb.ko and modified drm.ko modules?

Oh, for rebuilding the package – to get the RPMFusion dependencies right you’ll need to specify –target i586 (or –target i686 if you’re on an i686 kernel) when building the modules. The architecture of the buildsys-build-rpmfusion-kerneldevpkgs-current dependency is actually dynamic, it’s generated from the target CPU for the build. So installing buildsys-build-rpmfusion-kerneldevpkgs-i586 and then rebuilding the .src.rpm with –target i586 should work (that’s how I built it).

Having said all that – I haven’t tried on 2.6.29 yet, because the wireless adapter in my P doesn’t work with the latest 2.6.29 from Koji (it can never connect to my router). Does yours work?

adamw: Yes, WiFi works (including WPA) with vanilla 2.6.29 from kernel.org and userspace tools from FC10 updates. IIRC I set up some config files manually, but that’s mostly because I am not familiar with the redhat GUIs.

it’s possible one of the changes in that patch (the complete removal of a line) is the ‘wrong’ fix. I’m not a kernel hacker, I derived that fix from similar changes made to other drivers that I found on Google. So if you actually know more than me, you might want to check if it’s the right fix for this case. 🙂

That patch is only applied for 2.6.29 (not 2.6.27) – on 2.6.27 it builds unpatched and doesn’t actually build after the patch – so there is a difference there: I haven’t actually tested yet if it works patched myself. So it’s possible that’s the problem.

OK, one problem was that my kernel had CONFIG_FRAMEBUFFER_CONSOLE disabled, and psb.ko apparently cannot coexist with a regular text console. I now have basic 2D acceleration on 2.6.27.23 with a heavily customized kernel config, thanks !
On 2.6.29, X still triggers oom-killer on startup.

Hmmm, I only just discovered the xrandr/multihead fiasco:http://modeemi.fi/~tuomov/b/archives/2008/07/13/T18_03_06/
I.e. recent X drivers do not support “zaphod mode” (multiple X screens) anymore. It looks like the ATI people have re-developed the functionality on top of xrandr, but the intel driver (which psb is based on) has dropped it entirely.

This means only a few window managers will be usable with a dual-head setup on poulsbo…

That’s an extremely misinformed post. RandR provides perfectly good cues for window managers to deal with multiple screens appropriately. GNOME / metacity work very well with RandR 1.2-based multiple displays, I have used such setups extensively. KDE rather screws it up in some ways, but that’s KDE’s fault, no-one else’s.

So you tested two mainstream window managers, and only one of them supports RandR hints correctly. I would say this confirms my opinion 🙂 (kwin probably handles RandR now, though.)

Needless to say, most of the lesser-known window managers support neither RandR nor Xinerama – and they didn’t need to, since X configured with multiple screens had been providing reasonable multihead functionality for about 20 years.

Besides, nobody will bother hacking RandR support into every single WM on earth, because everybody expects RandR 1.3 to fix the problem sometime in the future. In the meantime I am stuck with clone mode.

Adam, we tried these src.rpm on a custom poulsbo platform, and it seems to have version incompatibilities. Where can we find a complete list of versions used for your test (for xorg, xserver, mesa, kernel, …) ?

I’m not sure, I don’t have the 3D working. The Ubuntu forum thread has lots of success / failure reports about the 3D. Probably the easiest thing to do is just see if compiz works, if it does, the 3D’s running well.

I’ve been using Fedora 10 with all your above rpm and I have a mismatch version in kernel modules. It seems the modules (drm.ko and psb.ko) are 2.6.27.21-170 version and the kernel in Fedora is 2.6.27.21-170 version. Is there a way to overpass this issue? Do I have the wrong modules version?

hey guys,
thanx adam for those packages. that’s really helpful… even though I could not get to compile them 🙁

I have the dell mini 12. it was shipped with the dell customized version of ubuntu.
reiv: glxgears gave a rate of 900…

anyway, I wanted to blast it out and to go for gentoo (I’ve been using it for 7 years)

1) I could not get to compile the kernel mod neither the xorg driver.
my kernel is a 2.6.28 with the tuxonice patches (is 2.6.29 mandatory?).
here is the error line of the compiler:
“include/linux/mmzone.h:277: error: ‘MAX_NR_ZONES’ undeclared here”

2) for the xorg driver:
”
mm_drm.c: In function ‘bufMask’:
mm_drm.c:207: error: ‘drmBO’ has no member named ‘mask’
”

do you guys have any idea for a fix?

reiv: you wrote you successfully compiled those. could you give some details on that? a quick how-to would be perfect 🙂 🙂 🙂

I am trying to make the Poulsbo driver work on Debian system. Does anybody has any pointers on how to get started on this? Can I just convert the rpm packages to deb using alien and install them? I do realize that I will still need to compile the psb drm module for my existing kernel.

Or else if I have to build all the deb packages from the source, how do I get started? I am willing to spend some time on this but I need some direction as to how to proceed. Thanks

Ok, last week I tried to get the psb driver work on Debian (5.0) using your sources. I was able to build the modules successfully and during boot it seems that the psb framebuffer module is getting loaded as my screens goes off for couple of seconds from ugly console and then it comes back with crisp resolution on the console while it is still booting.

However, as soon as my Xserver starts I get the following error message in my Xorg log file:

Adam, firstly I am completely new to Linux so excuse my wet behind the ears questions. I have found your blog invaluable in a number of areas the past week or two whilst I ‘learn the ropes’ having installed Ubuntu.

Where I am still struggling, is one of your favourite subejcts; the video driver on the VAIO-P. I have followed your instructions, seen to have got the driver and packages installed operationally, however am still getting the “framebuffer” error you mention in your post.

I have entered the mem=1500MB line, also trying different figures but it makes no difference. Same error and back to VESA.

Any help or thoughts you can provide would be greatly appreciated. As for Ubuntu, I am loving it; it has really made the VAIO-P come alive after being tied down under Vista to a grunting, hard to use piece of kit.

hi guys,
I finally managed to compile the psb kernel modules against a 2.6.29 kernel.
I also copied the firmware to /lib/firmware (looking at the kernel’s logs, it seems the psb kernel mod needs it at probe time).

For what it’s worth, I now have psb running with linux-2.6.30.2 and FC10 on the Vaio P. Earlier attempts with linux-2.6.29 failed with mysterious OOM errors. This time I used sources from psb-kernel-source_4.41.1-0ubuntu1~904um1_all.deb, with straightforward fixes.

But Xorg still hangs after a few hours: The display freezes (except the mouse pointer) and Xorg.0.log says “[mi] EQ overflowing. The server is probably stuck in an infinite loop”.