Man, it’s been awhile since I blogged. I meant to keep putting up a monthly Xfce desktop, share some tips, talk about the latest Gentoo work, etc. And then real life got in the way.

Laptop

I killed yet another piece of hardware when updating my Thinkpad R61i on Friday. I’ve been sick this whole week, so I had some free time. The laptop hadn’t been updated since early February, so there were 176 packages, including the big move to GCC 4.3, which necessitated a system rebuild. Unfortunately, I left the battery in while the system was on AC power for the compiling work. I guess the heat must have built up too much, because the battery got fried. Got the dreaded “battery light flashes amber rapidly” error. So now I only have the extended-life battery, which is heavier and bulkier.

Add that to the list of hardware that compiling Gentoo has killed over the years. The list includes another battery, an external power brick, an internal PSU, two motherboards, two RAM sticks, one RAM slot, two hard drives, and a fan. I’m really on a roll, here.

I still can’t find a replacement battery for less than $90, even on eBay, so I may hold off. What I did do was order two more gigs of RAM, to bring the total up to 4GB. Only cost $40 at Amazon, free shipping. Why the RAM? While updating, I ran into the dreaded OOM-killer! The GCC 4.3 compile uses more than the 2GB available and it aborted the merge. This was with nothing else running, too. So be warned: if GCC dies when you move to 4.3, back off on your MAKEOPTS. I had to adjust mine from -j3 to -j2 while compiling GCC and glibc.

Also, while I was updating my whole system, I decided to move the rest of my X/kernel stack to ~arch, as I wanted the new Intel KMS/GEM/UXA hotness. This necessitated using ~arch xf86-video-intel and Mesa, as well as ~arch gentoo-sources, as 2.6.29 has some needed code not present in 2.6.28. I discovered that while this part of the graphical stack was just fine for KMS and fast graphical login, xorg-server-1.5.3 resulted in hard lockups as soon as I opened any windows. I had to grab xorg-server-1.6, libXfont, and randrproto from the X11 overlay in order to get a usable environment. It works great! No more lockups.

So, how much of an improvement is the new stack over what was available in February? I’ll let the following numbers speak for themselves. These are the median-high numbers recorded. For the old stack, the numbers varied from 48FPS to 59FPS. For the new stack, from 489FPS to 504FPS. Sync to vblank and vsync have never been enabled.

xorg-server-1.5.3-r1, libdrm-2.4.4, xf86-video-intel-2.6.1, mesa-7.3, gentoo-sources-2.6.27-r8

$ glxgears 
Failed to initialize GEM.  Falling back to classic.
292 frames in 5.0 seconds = 58.272 FPS

xorg-server-1.6, libdrm-2.4.6, xf86-video-intel-2.6.3-r1, mesa-7.4, gentoo-sources-2.6.29-r1

$ glxgears 
2516 frames in 5.0 seconds = 503.174 FPS

Now, the usual caveat about glxgears not being a good benchmarking tool applies here. However, it is useful for relative comparison from one version to the next. And as you can see, it’s an order of magnitude better. I notice that stuff is drawn much smoother; there’s less flickering especially when shifting Terminal windows around. And I haven’t hardly begun to tweak my system for best UXA performance. KMS is nice and smooth; it happens pretty quick in the boot process. No more flickering, just fast loading of SLiM and then Xfce.

My xorg.conf is pretty minimal; the only changes I’ve specified for the Intel driver section are these:

Option	    "FramebufferCompression" "false"
Option	    "AccelMethod" "UXA"
Option      "Tiling" "false"
Option      "EnablePageFlip" "true"

There are probably some other things I should add for maximum performance, so I’ll have to spend several more days hunting for ‘em. But out-of-the-box, I’m extremely impressed with the current X stack.

Now all I need is smooth full-screen Flash video performance . . .

Xfce 4.6

The other thing I put on the laptop was Xfce 4.6.1. Decided that as long as my core graphics stack is part ~arch, it wouldn’t hurt to try out the latest and greatest Xfce hotness. Now that some outstanding bugs were fixed from 4.6.0 (including a remote security bug, and an icons issue), I thought it’d be worth it. It’s pretty slick. The desktop environment is initialized a bit faster than even a fully tweaked 4.4.3.

About the only outstanding issue I have with it is that there is no graphical menu editor. At first, I couldn’t get a satisfactory menu even editing the XML file by hand; it was just too different from the old one. So my menu was cluttered with useless toplevel entries, such as Web Browser, File Manager, and so on. Fortunately, Mike pointed me to the solution, so now all offending stuff has been cleared out. Right now my menu works just fine, so I only really need a graphical menu editor for convenience’s sake.

I really like 4.6 a lot. The artwork packaged with it is outstanding; I’m using one of the stock backgrounds because it’s just that sexy.

Xfce 4.6 is a smash hit, so well done, guys. Very well done. And there’s even more good stuff planned for the future. There’s a great interview on Planet Xfce with one of the core developers. He discusses some of the exciting stuff coming down the pipe for Thunar, so make sure to read it.

Gentoo

I’ve been rather quiet on the Gentoo front for the last three months, because life in the outside world has a way of unexpectedly intruding on me. I’ve been on devaway since February while I try to get stuff into some semblance of order. Sadly, however, I’ve had to do much more documentation work than I originally scheduled, which keeps cutting into my plans for other areas. I’ve made a bunch of bugfixes and commits over the last couple of weeks especially. One of the most visible changes is in the Get Gentoo page, putting the automated weekly builds at the top. The handbooks will be updated, too, but they require a tremendous overhaul, so I’ll need all the resources of my fellow GDP members to accomplish that. If I can get ‘em, that is.

One of the other things I like to do is find some interesting little-known application, determine its usefulness, then hack up an ebuild for it. It’s really good practice, actually.

Out of all the applications I’ve written and updated ebuilds for, the only one that’s got me stumped is WordGrinder. I’ve been in contact with WordGrinder’s upstream author, who’s a really helpful guy, but I still can’t get the ebuild working. While compiling and installing by hand works great, something happens during the compile phase as run by Portage where it violates the sandbox, killing the merge.

Plus, given the pmfile used by the package, it doesn’t really respect a user’s CFLAGS/CHOST and related configuration. That has to be altered somehow, so I’ve been trying to work out a similar solution to the one used by our dev-lang/lua ebuilds. No real luck there, but it’s not my first priority. What I really want to do is have the merge workin’ with Portage. So it’s an interesting, informative, occasionally frustrating learning process.

Anyway, take a look at all the stuff in there. I recently reorganized the ebuilds by category/package, instead of dumping everything into a single directory. Some of these have since moved into Portage sometime after I wrote the ebuild for ‘em, and some (like Songbird and WordGrinder) are works in progress. I’ve run into quite a few nifty apps; places like GnomeFiles are excellent resources. Most of the stuff in here I discovered on GnomeFiles, and a lot of the packages on the website are simple enough that it’s just a few minutes’ work to hack up an ebuild.