Catalyst vs. Mesa (round 2)

In February, I wrote about my frustration with AMD’s binary Catalyst drivers and my switch to the free Mesa drivers for my media/gaming system. During the summer, I updated to Fedora 13 and continued to enjoy the reliability of free drivers.

Then, a problem. Sometime in September, some of the rendering in XBMC started to be corrupted. Movies played fine and the picture slideshow continued to work correctly, but any controls rendered on top of the Movie or slideshow seemed to be missing the background texture and instead rendered as a very light grey. With white text rendered on top of it, it made the controls pretty unreadable.

Upgrading mesa didn’t work. Neither did upgrading the kernel or XBMC. And a full upgrade to Fedora 14 didn’t help either. Given the insanity of getting everything else up and running at the beginning of the school year, this was the point that I stopped. After all, our main use of the system is to watch movies or the pictures slideshow, and, though annoying, the bug wasn’t a show stopper.

With some of the free time we had for Christmas, I decided to try to tackle the bug. I figured the easiest way would be to go back to the Catalyst drivers and see if the rendering was still screwed up. Sure enough, the Catalyst drivers fixed the rendering. I then tried to open Nexuiz full-screen over XBMC. The display froze. One reboot later I tried again. And the display froze again.

After several hours of trying different kernel and xorg.conf options, I was ready to put the computer in the middle of the Damascus highway during rush-hour traffic.

Then I had an epiphany. In Fedora 15, the r600 driver will switch from the standard Mesa driver to the new Gallium3D driver. So I installed fedora-release-rawhide and then did a:

yum update mesa-* libdrm-* xorg-x11-* gdm-*

One reboot later and XBMC is rendered correctly in all of its glory, all of my games run correctly over it, and I still don’t have to worry about keeping Catalyst up to date.

Closed drivers: 0

Open drivers: 2

Note: Some may wonder why I updated gdm. For some reason, the old version interacts with X in such a way that X crashes and I’m left with the boot screen and can only ssh into the system. It seems to be somewhat related to this bug, and updating gdm fixes it.

Back to the (i386) bottle

In the spring of my last year at Washington State University, I bought an eMachines M6807, one of the first reasonably-priced laptops with a 64-bit processor in it. I almost immediately installed a 64-bit distribution on it, and then almost immediately went back to 32-bit (if I remember correctly, it had a Broadcom wifi card that could only be used with 32-bit ndiswrapper).

Somewhere around the time the b43 driver came out, I switched back to 64-bit Fedora and, in the two laptops since then, have stuck with it. Until today. When I upgraded from Fedora 13 to Fedora 14, I started running into memory problems, and it finally came to a head today when Firefox, Evolution and Eclipse combined were enough to make my laptop start swapping. Heavily. The hard drive light may be pretty, but watching the desktop sitting unresponsive isn’t my idea of fun (or of being productive).

I have 3GB of RAM on this laptop. There should be little need for swap, and no thrashing at all. I decided to install Fedora 14 i386 on a second partition and see if it made any difference. Sure enough, with Firefox, Evolution and Eclipse open for several hours, I’m currently sitting at 815MB used, 2185MB free.

So where do I even start filing a bug on this?