.comment: Help Comes From Unexpected Places - page 3

Waist Deep and the Water's Rising

My new, high-powered video card had been roundly praised as one of the finest in the world, leading me to suspect that properly configured it would deliver the performance I sought. I started on the XFree86 home page where, digging a little, I learned that 3-D is lightning-fast because it is directly rendered--so long as you're running XFree86-4.01 and Linux 2.3.99 or better.

Well, okay. Linux-2.4.0-test4 was current at the time, so I downloaded the source and burned a new kernel. (By the way--2.4 is going to be tremendous, but from what I see on the kernel mailing list, I don't think it will be with us real soon now. A couple months at least.) I included frame buffer support, AGP support, support for my motherboard's VIA chipset--all kinds of good stuff. It worked, as expected, right off the bat. This because of other unexpected places where help is available. For instance, no one should even dream of building a new version of the Linux kernel without reading the Changes file in the Documentation subdirectory of the kernel source. This isn't some changelog, it's a listing of the non-kernel packages that you need to upgrade if you want this kernel to compile and work. It also lists the places to get all the updated packages. (It's a good idea to read the docs for them, too--it wasn't until PPP failed that I learned that with the new PPP one must create a /dev/ppp.) And if one builds the kernel with make xconfig, almost every possibility--and there are many--has a complete, readable, and often funny helpfile.

An aside: Did you know that the source code in /usr/src/linux should not be that of your new kernel but instead that of the kernel against which your glibc was built? I didn't, but no less an authority than Linus himself pointed this out recently, and when it comes to the kernel he is by definition right. This was a puzzle, because some applications, notably XFree86, go to the Linux source at compile time, and I wondered what happens when it's not the same source as was used to build the kernel.

The new kernel working as it should, I downloaded the binaries for XFree86-4.01. The install script provided works very well. The new X configuring tool, xf86cfg, is pretty awful in that it never did produce a configuration that would work here at all. Worse, the whole business produced exactly no improvement in performance. I asked on one of the XFree86 mailing lists and was told that I needed to make sure that I had the proper kernel module, mga.o, loaded. I not only didn't have it loaded, I didn't have it period. Someone mentioned that this would get produced by compiling the DRI source.

Some more research led me to the development site for DRI, the direct-rendering interface for XFree86--the stuff that lets X manipulate your video hardware directly. There isn't some DRI package waiting to be downloaded; you have to get it by anonymous CVS. I did so, read the installation document (which is found, unexpectedly, with the XFree86 docs, which are themselves found in the unexpected /usr/X11R6/lib/X11/doc directory, probably not the first place a newbie would look; though a version of DRI is included in XFree86-4.01) and compiled and installed the thing. Mind you, this is CVS code, meaning that it is in some respects pre-alpha, so the fact that it works at all is more than one can expect with any confidence. It did work, somewhat. You will be unsurprised to learn that the increased frame rate in GL applications was not there. You might be surprised, as I was, that so much as trying to start a GL anything--demo, screensaver, whatever--would now lock the machine up tight. Absolutely solid. Reproducibly. For years I had not been able to lock Linux despite constant abuse of it. E2fsck takes a long time on a 20-gig IDE drive. And I got to experience it a lot, as I attempted, unsuccessfully, to fix the problem, with each attempt returning the same result, reboot, fsck....

A post to a KDE list resulted in my introduction to a fellow named David G. Watson. This is one of the best aspects of the Linux help system.

Everyone should have a Linux guru. Mine is Bob Bernstein. When I've well and truly broken something, I can email or, if I've really screwed things up, phone him. He has a multitude of distributions either currently running or capable of being booted at once, all the time. My first week with Linux would have taken a month but for his help. He's brilliant, knowledgeable, down-to-earth, and willing to give of his time to help others with Linux trouble. But people have their specialties, and hacking X isn't one of Bob's many.

There are a lot of people who have at least some of those characteristics, and some who have most or all of them, and David G. Watson falls into the latter group. He spent a lot of time over the next few days helping me sort out the GL situation. The mga.o module, he told me, does not get automatically installed and needed to be copied by hand and started by hand. Lo and behold, it hadn't even built! DRI, which like XFree86 itself uses the obscure imake in addition to the more commonly encountered autoconf and make, needed to have a line uncommented in order to build the modules. So I recompiled--but the build blew up in the 3dfx module, before it got to mga.o. Editing of the appropriate Makefile.linux cast 3dfx into oblivion and soon I had my mga.o.

Mr. Watson spent a lot of time trying to sort out my situation, all by email. In the course of it, he taught me a great deal about the workings of X. All this just because I posted a question to a mailing list. We were finally both defeated, though I suspect that had Mr. Watson not been in Ohio but instead here in Connecticut, he probably could have solved the problem in five minutes at my keyboard. I figured I had been communicating with a computer professional of some sort. I asked. David G. Watson graduated this year from high school--he was home schooled--and will start his computer science studies at Kent State next month. Help from unexpected places.