K.Mandla's blog of Linux experiences

What was I thinking?

Actually I know exactly what I was thinking. I was thinking, “Gee, it’s been a year since I had a graphical desktop on this computer. I should check and see if things are working again.”

And you know what? They’re not. It was issues with the siliconmotion driver that initially drove me away from X, and in all that time, things are still gunked up. Maybe I was expecting too much. Or maybe the hardware is just too darned old, and everyone else with a Silicon Motion card has a machine a good deal newer than this one.

Regardless, after a rather fitful installation of Arch Linux, I discovered that the 1.7.3 version of the driver and the 1.7.5 version of xorg-server still spatter garbage across my desktop. A year later, and moving windows creates wakes of multicolored pixels. A year has passed, and typing causes splattered rainbows inside text boxes. Twelve long months, and the cursor leaves white smears everywhere.

Oh well. It was worth a shot.

I am not without options of course, since there is always the vesa driver to consider, as well as the fbdev driver. In my case only fbdev actually gave me a working desktop, since vesa only sent me to a dead black screen. fbdev isn’t much of an option either, since there’s a heavy flickering effect when I move windows, and screen redraws are painfully obvious. Better than nothing, I suppose.

But perhaps even more frustrating was the fact that I could only have one driver installed at a time, since any xorg.conf file I built was promptly ignored by X. If I didn’t want it to pluck the siliconmotion driver from the throng, I had to yank it out completely.

That I blame on hal, since I also couldn’t get the Japanese keyboard configured in a standard (the old standard, maybe?) xorg.conf file. I tried to manhandle hal’s fdi files, buried deep in the inconvenient /etc/hal/fdi/* directory. But adding almost anything to hal’s little world (XML … yuck) either had no effect, or caused a complete loss of keyboard input. Somebody throw me a bone here. It can’t be so frustrating to get an international keyboard set up under hal with Arch.

I am sure 100 percent of these complaints are attributable to my inexperience using Xorg with hal in the driver’s seat. Perhaps if I had spent a little time with it, I would be able find exactly the file that needs editing, or the tweak that needs setting, that would allow me to type properly in X, or set one driver over another as my preferred form of output.

But I must confess I don’t have the patience. It’s not that spectacular to me, to be able to use a Windows XP-ish IceWM on a 550Mhz Celeron. Because even in the best case scenario, with that same setup running with fbdev as the video driver, the system requires more than twice as much memory, plus as much swap, just to stream music over a network connection. And add to that the CPU is usually hovering around 40 percent workload, according to htop.

Video playback is workable, but was better when I had the entire machine at my disposal. And it goes against my grain somehow to think that I now have X as an interpreter between me and mplayer, and it’s (sort of) using the same method of output as my home-grown framebuffer-only custom-built mplayer.

I know most folks count me amongst the stranger eggs in the basket for running a console-only system against the framebuffer 24-7, but really, what do I gain from a graphical setup? A groggy system, sloppy window redraws and not even the scant 3D acceleration that I should have with this graphics card?

No thanks. I’ll stick with what I know. I cloned the drive before installing Arch, and it’ll only take me an hour and a half to put the old system back in place over USB1.1. Always have a Plan B. (Or was it C … ?) ;)

My primary free Unix choice is OpenBSD, which doesn’t have anything like Linux’s framebuffer, so I use X and try to keep it fairly minimal. In fact, I often run without a window manager at all, and just launch a big Xterm via .xinitrc (which in turn runs tmux).

Of course, this is probably all just sillyness on my part, as I’m not really running on low end hardware; I just love minimalism and the Unix command line paradigm. My desktop is a Dell Dimension e520n (1.86ghz Core2Duo with 4GB of RAM) and my portable is a Lenovo IdeaPad S10 (1.6ghz Atom with 1.5GB of RAM).

My 500MHz P3 laptop/server is X-less. Fluxbox went ok on it but I didn’t really gain anything since I have better computers if I want a GUI. I enjoyed setting up a console-only system as a means of learning something and helping to make the most of the flotsam and jetsum that was flowing my way :D

The Arch Wiki ist pretty detailed when it comes to Xorg and Hal.
The section titled “i don’t want this crap, how do i turn it off?”,rather aptly put imho, describes how to stop hal from being a bastard and grabbing everything. I still use xorg.conf, I just gotten by KMS which is default in kernel 2.6.33 when using intel or ati chipsets, which ignores lots of xorg.conf settings. another possibility concerning the weird colours is 16 bit. Recently 16 bit has shown issues on all kinds of chipsets, maybe trying 24 would help. Here’s the link to the wiki: