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: libdrm-poulsbo psb-kmod psb-firmware xpsb-glx xorg-x11-drv-psb 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): libdrm-poulsbo libdrm-poulsbo-devel (you only need that if you want to rebuild any of the other bits) kmod-psb-2.6.27 kmod-psb psb-firmware xpsb-glx xorg-x11-drv-psb 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: 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 EndSection 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.

yes! I have psb up on Fedora 10. I just had it driving the P's internal panel at 1600x768 and my 20" monitor at 1680x1050 - side-by-side. which is actually pretty impressive. It has a decent RandR implementation. Details and packages to come, I'm still twiddling with some bits (like why it doesn't work unless I pretend I only have 512MB of RAM...)

Ah, look - don't say I didn't tell you so. (As always, these posts are entirely my own personal opinion and not in any way related to employers current, past or future.) Here's Canonical, revealing at least one way it's going to try and monetize Ubuntu. Here's the shit, hitting the fan.

Is it a bird? Is it a plane? Is it Will Woods lovingly caressing his Thinkpad's fingerprint reader for the sixty seventh time today? No, it's - another Test Day! Yes, this Thursday - May 14th - will be a Test Day for iBus, the new default input method framework for Asian languages for Fedora 11. As always, it'll be held in #fedora-qa on Freenode IRC (see this page if you're not sure how to use IRC). The exact time is quite flexible, we will have developers, QA folks and testers all the way through 'Thursday' for both Asian and American timezones, most likely. If you type in an Asian language, this is a really big deal for you. If you don't, well...it's not. If you do, though, please do come out to the Test Day! This is one of those things that's crucial for some people and completely impenetrable to others, so we really need as many as possible of those who need it and understand it to come out to the Test Day and make sure it works. Here's the good stuff: the testing is pretty easy, and there's a live CD, so you don't need to have any version of Fedora installed at all to do the testing. So even if you don't use Fedora, you can help out the development of iBus - and hence all distributions, as they all either use it already or will be in future - by coming out to the Test Day and helping to test this new framework. If you don't, and Fedora 11 (or the new version of your favourite distribution) comes out and you find you can't type Korean any more - you've no-one to blame but yourself! Well, you and whichever idiot left the bug in the code. But mostly you. So come on out!

that was the biggest pile of bullshit ever (and remember I'm a Mets fan who remembers the last two seasons all too well). we played a fantastic game of hockey, scored five top class goals, comprehensively outplayed the hawks in every area of the game all night...and lost on a barrage of ridiculous bounces and terrible penalty calls (go look at the interference calls that *were* made on the canucks, and the ones that *weren't* made on the hawks, and tell me it wasn't bullcrap). christ. seriously. it's not as bad to lose if you suck, but that was ridiculous.

From Stephen John Smoogen, on fedora-devel-list this morning: "When dealing with anything with Oracle.. one has to look at where the money is. Oracle will say a lot of things but what they do will be what gets Larry Ellison another yacht."

So farewell, 3D Realms - or, rather, Apogee, as I always thought of them... The second oldest computer games I really remember playing are Commander Keen and Crystal Caves, two of the classic side-scrolling platform games Apogee brought out under the shareware model it more or less pioneered, giving away a third or so of the game and charging you for the rest. In my desk drawers I still have five of the old brightly-colored instruction / advertising sheets they used to ship out with paid copies, for Commander Keen, Crystal Caves, Duke Nukum (yes, that's how it's spelled on the original), Wolfenstein 3-D and Cosmo's Cosmic Adventure / Word Rescue (that one was double-sided). I was (and, technically, still am) the last maintainer of the official Wolfenstein 3-D FAQ - thanks to which Apogee would occasionally send me cool schwag, I still have a notepad and a copy of the original strategy guide at home - and Apogee offered me my first ever job in the tech industry, ironically doing much the same work I later wound up doing with Mandriva. (As it would have required relocation to Texas, and I was 13 at the time, I had to decline). So, not really much to say except how cool and old skool I am. :) The unfashionable type of old skool as well - while the other kids were playing with their Italian plumbers or improbably hued hedgehogs, I was saving the galaxy in a bean-powered rocket. I wonder when I should put this stuff on eBay...:|

Crosby? Ovechkin? Pah. Best goal of the playoffs - Rick Rypien to Darcy Hordichuck. believe it, foos!

Tomorrow - Thursday May 7th - will be a Test Day for virtualization for Fedora 11. As always, it'll be held in #fedora-qa on Freenode IRC.

We'd really like to get as many people as possible out to help test. What's up for testing are the virtualization technologies Fedora has done a lot of work with: KVM, qemu, libvirt, virt-manager and the like.

I've noticed when you start talking about this stuff, a lot of people's eyes glaze over. Many people are used to using the lower-end VMware products and VirtualBox, because they're simple and easy to use for pretty basic virtualization cases. Whereas if, like me, you tried to run Xen or KVM / qemu two or three years ago, you probably wound up reaching for the Tylenol.

See, here's what I discovered when I decided to bite the bullet and give this stuff a shot again a few weeks ago: it's nothing like that any more. Take a look - there's some screenshots of virt-manager. It's really just a UI on top of some of those scary virtualization technologies - especially qemu and KVM - but it works in a surprisingly similar way to, say, VirtualBox. You get a simple graphical interface with a nice wizard for setting up a VM, which you can then just run with a single click. It's nothing like the scariness it used to be.

Yes, things can get a lot more involved if you have complex needs, and some of the planned Test Day testing covers those areas. But a lot of the testing is on pretty basic stuff that just about any casual geek will be able to wrap his or her head around. This technology is really cool and it's a worthwhile benefit to have a cohesive virtualization stack which covers everything from basic VirtualBox-type functionality up to the scary VMware enterprise stuff on the top end, all based on the same technologies that are very open and upstream-friendly. So really, if you have any interest in virtualization, come along and help out! It's really not difficult, and there will be plenty of experienced developers and testers in the channel to help you over any bumps you encounter. There's also links to Getting Started documentation right on the Wiki page, so you can go ahead and set up your environment ahead of time.

You'll need a Rawhide installation, but now we're in the run-up to Fedora 11, Rawhide is pretty stable; it's not as dicey as it would have been a few months back. All you need to do is install Fedora 11 Preview and do a regular update - there's instructions on the Wiki page. Some tests do require hardware virtualization support, but not all of them - so even if your CPU and BIOS don't provide hardware virtualization support, you'll be able to help with some testing (though the virtual machine will run quite slowly).

So please do come along and help us test this stuff tomorrow! It's a really exciting area of development that will lead to some cool code in Fedora 11, 12 and future Red Hat releases. Thanks. Remember - #fedora-qa, Thursday May 7th.

In a shockingly work-related post - this morning I got a bit inspired, and made extensive revisions to the Fedora bug process page. Hopefully, nothing's controversial, just a better documentation of the existing process. One significant thing it formalizes was discussed at the QA meeting this morning: what happens when a Rawhide bug gets fixed. It's never really been clear if it must go through MODIFIED / fix confirmed by reporter before it goes to CLOSED. We agreed at the meeting, and I've written in the page, that it should be optional and up to the maintainer: if you fix a bug in Rawhide, you can either set the bug status to MODIFIED and ask the reporter to confirm the fix, or - if you're confident and just don't want the hassle - close it as CLOSED RAWHIDE immediately. It's easy enough for the bug to be re-opened if the fix didn't actually work. Aside from that, I just re-arranged it in a more logical order, wikified it, and added a lot more detail on bits of the process, states, and resolutions that weren't previously covered. It also now explicitly mentions which resolutions and states are valid for Fedora and which aren't. I'm expecting for this to be the definitive reference for the Fedora bug lifecycle. If that's OK with everyone, I'll ask for the page in Bugzilla - which, in practice, mostly covers RHEL - to have a note added which says it's about RHEL, and to look at the Wiki page for Fedora. Trying to cover both different processes on one page would probably get rather messy.