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 … ?) 😉