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).
Here's the .src.rpm's:
And here's binary packages, for Fedora 10 fully updated with kernel 18.104.22.168-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:
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:
Section "Screen" Identifier "screen1" Device "Videocard0" DefaultColorDepth 24
Subsection "Display" Depth 24 Virtual 3280 1050 EndSubsection Subsection "Display" Depth 16 Virtual 3280 1050 EndSubsection Subsection "Display" Depth 15 Virtual 3280 1050 EndSubsection Subsection "Display" Depth 8 Virtual 3280 1050 EndSubsection
but once you have that, the chip is capable of driving my setup - the P's internal 1600x768 display, and an external 20", 1680x1050 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.