April 24, 2019

.comment: 86ing XFree?

When Good Code Goes Goofy

  • December 13, 2000
  • By Dennis E. Powell

Can we agree that XFree86 has become a mess?

If you don't, download the current CVS tree and try to make some sense of it. Or, if your connection is such that you really can't spare a couple of days to get it, download the source for XFree86-4.01 and take a look. For an extra-special good time, try building it with direct rendering (DRI) support and a kernel module for your 3-D video card. See what I mean?

Ah, you probably thought that the docs would help you. Lots of luck. The INSTALL.TXT in the top-level directory of the source was last updated just under three years ago. Here's a typical passage, pasted from that file:

"Edit xxcc//ccoonnffiigg//ccff//ssiittee..ddeeff for local preferences. If you want to install somewhere other than //uussrr//XX1111RR66..44, change PPrroojjeeccttRRoooott. (Do _n_o_t use DDEESSTTDDIIRR.) If you want to build with _g_c_c uncomment the HHaassGGcccc22 line. If you have _g_c_c, but not _c_c, please read the full build instructions."

And that is the first paragraph of the "Easy Build Instructions."

Now. XFree can be built. I've done it several times. Because it relies on the hoary old imake, it requires skills otherwise long dormant, or acquisition of new skills that are unlikely to be of use anywhere else. The compilation produces--or comes to a halt because it cannot produce--all sorts of stuff that it is guaranteed you do not need. The resulting binaries can conflict with whatever is already on your machine such that it can lock solid--I've encountered this with dueling GL libraries--and sorting it all out is mind-bogglingly difficult.

What's more, the current XFree86 configuration tools are just awful. There is no longer an XF86Setup. The old, console-based standby, xf86config, fails to recognize a lot of modern hardware: We now have video cards with lots of memory, and we have monitors manufactured in the last few years that are--surprise!--different from the ones built earlier. There is a new configuration tool that I have yet to see produce a useful XF86Config file on any machine anywhere.

Indeed, I endured several months during which my monitor would not hold horizontal sync. I'd provided the correct parameters both for it and for my video card, a Matrox G400 with 32 megs, scarcely something exotic or unusual. And it just wouldn't work.

Finally, in desperation, I thought I'd tweak the modelines a little. But XFree86-4.01 does not by default have any! In order to get the thing to work, I ran a copy of XF86Setup from XFree86-3.3.6, produced an /etc/XF86Config, and pasted the modelines from it into my /etc/X11/XF86Config. For 1280x1024, the resolution I favor, the modeline was this:

Modeline  "1280x1024" 135.00
1280 1312 1416 1664 1024 1027 1030 1064

And still no horizontal sync. I began playing with the first number, 135.00. First I cranked it down to 125.00. Horizontal sync was just fine, but the refresh rate was low. I began tweaking it upward. As I did, the refresh rate increased. The sync remained just fine. It maxed out at 142.00, which gave me 1280x1024 @ 85Hz. (After that, it dumped into 1600x1200 @ 60Hz., which was briefly interesting but nothing I'd care to live with.) In my incremental testing I discovered that of all the possible values, 135.00, the one calculated, was the only one that didn't sync. A system that allows you to have reliable graphical video only if you experiment and hack, at the risk of blowing up your monitor, is not necessarily the best choice for general use. No wonder people (often secretly, lest they be thought impure for having actually paid for software) explore the commercial alternatives.

Most Popular LinuxPlanet Stories