It began with eyecandy.

I like eyecandy. In that category, there is nothing better in Linux than Jamie Zawinski's XScreenSaver, and there has never been a better version of XScreenSaver than the newish 4.0. Within 4.0, there are no screensaver modules more visually pleasing than the GLX ones -- the 3-D, OpenGL modules -- as long as you have hardware support.

A week or so ago I sought to get and install XScreenSaver 4.0. Thus began a journey involving a great deal more.

Without hardware support, the GLX modules look like the slowed-down Zapruder film that is shown forever on one of the four cable television channels (they seem to trade formats, but can be described as "The Tornado Films With Bad Background Music Channel," "The Shark Channel," "The Really Disgusting Surgery Channel," and "The Goofy Kennedy Assassination Theory Channel"). With hardware support, they are smooth and quick and cool. Sad to say, but getting hardware support to work properly in Linux with XFree86 has never been all that easy. I spent days and days working on it a year or more ago. Since then, I've switched to a different distribution -- SuSE -- which does its best to deter users from setting up hardware support -- "direct rendering" -- at all. The reason I was given when I asked was that SuSE doesn't think it's sufficiently stable. They have a point, but properly managed, OpenGL stuff isn't likely to bring down the house or the machine.

My first attempt building XScreenSaver 4.0 ended when, at ./configure, I was told that the libraries necessary for the GLX modules were not installed. I went to the SuSE CD and installed them by trial and error until I got the results I wanted. XScreenSaver built, then, with no problem. It installed with no problem. It ran with only one problem -- the tick-tick-tick effect in the OpenGL modules.

In that my guess was that I was going to have to recompile XFree86 anyway, I thought that it might be a good time to upgrade from 4.1 to 4.2. And in that I'd read of some rare but troublesome bugs in 4.2 that had been fixed in the XFree86 CVS tree, I downloaded it from there.

Compiling XFree is always a little frightening, not because it is difficult but because it is different. Instead of the ./configure, make, make install routine with which most of us are familiar, one edits files, usually limited to /xc/config/cf/host.def and/or site.def in the same subdirectory, then does "make World >& world.log", then waits, then inspects world.log for evidence of disaster, then backs up the working XFree on the system, then does "make install >& install.log." Then restarts X to see how it all worked out.

My custom is to build XFree with no changes, to see what's broken and in need of fixing. In the past, there were always changes necessary to get GLX support and to get Freetype -- typeface anti-aliasing, another crucial eyecandy element -- working. Not this time, though. It was really startling. Everything worked. I hadn't needed to edit any files at all!

On a roll, and because sooner or later I was going to need to take another look at it, I downloaded the latest KDE3 source, which was now labeled Beta 2, and began the considerable process of compiling it. This begins with qt-copy from the CVS tree -- it really ought to be made available elsewhere -- which is the latest release Qt with hacks and patches. A tip that anyone undertaking a build of qt-copy is likely to find essential: first thing, do "export YACC='byacc -d'" because the GNU bison does not work.

The kdesupport package is supposedly deprecated and no longer necessary, but I've always found it a good idea to make and install it first anyway, which I did this time. Kdelibs built just fine, but kdebase blew up. I took a look in the kde-devel mailing list archives, found nothing obvious, posted a question to the list, didn't hear back quickly, and went back to the archives for a more thorough search. After awhile, and several tunings of my search terms, I found that the problem was due to my having less than the latest zlib aboard. So I got and built the latest zlib, and installed it, and ran /sbin/ldconfig -- and hit the same problem in the same place building kdebase.

"Locate zlib" gave me cause for a minor rant, in which I will now indulge: Look on your machine. You have zlib all over the place. Here, it was in the kernel source, it was in the Java Development Kit, it was spread out over /usr, and it was in /usr/X11R6. Four copies -- no, four different versions -- of the same library, each going its own way. There are probably very good reasons for this, but it's still ridiculous. And as Linux grows bigger and more complicated, it is going to create problems that grow at an exponential rate.

Seeking to solve the current problem, I did as advised in the archives and pulled the zlib stuff out of /usr/X11R6. Kdebase now built, as did the rest of the KDE3 source. (I have now been told that the version of zlib aboard is no longer critical to the successful compilation of KDE3.)

I was on deadline, so I did not go ahead and give KDE3 a spin -- in previous builds, KDE3 imported practically none of my existing configuration, and I didn't have time to reconfigure everything. I changed my /opt/kde and /usr/lib/qt symlinks back to my old, reliable /opt/kde221 and /usr/lib/qt-2.3.1 and restarted X.

And now hardware support in the OpenGL screensavers was broken. (To find out if you have hardware support, do "glxinfo" at a prompt, scroll to the top of the results, and see if you have "direct rendering: Yes".) So, as soon as I was off deadline, I took the very long way around -- I did "make clean" in my XFree86 source tree, went to /xc/lib/zlib and replaced everything there -- version 1.0.8, I think -- with the 1.1.3 I'd gotten to get kdebase to compile. Then I recompiled XFree and installed it. Now I had my direct rendering back.

(Pavel Troller reminded me a day or two later that all I needed to do was to put the line "#define HasZlib YES" in my /xc/config/cf/host.def file before building XFree to get X to use the zlib I had installed in /usr. Either way it meant an XFree recompile, though my delight in having needed to edit no configuration files had blinded me to this expedient.)

Imagine my chagrin when, during the following night, XScreenSaver apparently locked X, such that no input was accepted. I spent a good deal of time chasing my tail over this one: Was one particular screensaver module responsible? Was an overly enthusiastic cron job deleting something that ought not have been deleted? I wasted way too much time on this before it occurred to me that it might be a good idea to recompile XScreenSaver against X as currently installed. The problem -- fingers crossed here -- seems to have gone away.

(Jamie himself was of help in my search for an answer, though his first note was a couple of URLs "for how this is not my fault." He was right, of course, but it spawned a bit of a chill -- I remember a friend's old joke about how Microsoft technical support was "where you wait on hold for an hour to be told that you have an incompatible mouse pad." There was a lot of everybody blaming everybody else in the old days; I hope in the Linux sphere we remember that solving the problem is the actual object. And this is no comment on Jamie's response or his sterling work -- merely that it reminded me of those sad days.)

And with all that as prologue, I now changed my symlinks -- /opt/kde to /opt/kde3 and /usr/lib/qt to /usr/lib/qt-copy. Then I did "startx".

And I was amazed.

Next: KDE3 Has Come A Long Way »