Never feel frustrated or intimidated if something I suggest doesn’t work. For every one successful note I have here, I usually have three or four giant question marks.

Sometimes those question marks are interrelated, which makes them all the more frustrating.

For example, I have a terrible time trying to remember how to power off the backlight — not just blank the screen, but to turn off the backlight — on my console-only framebuffer systems.

As a result, and because I get tired of trying various options only to rebuild a kernel and waiting for it to (maybe) work, I get lazy and just start closing the lid on a laptop. The BIOS usually turns off the backlight for me.

But at the same time, most graphical X systems can turn off the backlight. Somehow. Magically. So as a troubleshooting measure, I decided to try building X on the 133Mhz Pentium file server and torrent slave.

It should work just as well as the Mebius, I figured, since they’re both Trident video cards and use identical software to display a graphical screen. Neither can do vesa, both are 800×600. Et cetera, et cetera. …

Except that the slower Pentium gets a whitewash effect with the trident driver. It almost looks like the screen is being over-charged or something, with a slow melting white smear that shows a faint shadow of a distended pointer.

Same card. Same generation. Same kernel version. Same Xorg version. Same package, same labeling, same compilation flags.

But the fbdev and vesa drivers, of course, don’t work, even if I recompile the kernel to support a framebuffer — which I originally didn’t.

So why does the Mebius get a proper 800×600 graphical desktop (with Musca and rxvt-unicode) under Crux, but the 133Mhz Pentium with comparable hardware doesn’t?

Beats me. I just work here. If I had all the little answers I could spend a lot more time chasing the bigger ones. One day I’ll get the backlight issue solved, and it won’t entangle me in other, stranger problems.

Of course, another one will come along. … 🙄