dpkg-reconfigure xserver-xorgI then logged out, in order to restart the GNOME display manager (GDM) and ... my computer hard-locked. No display, Caps Lock LED keeps blinking, no disk activity, no ping. Dead as a Dodo.
I turned the computer off, turned it on again and waited for GDM to come up. Same result - my laptop ended up quietly blinking its Caps Lock LED.
By now you've no doubt realized that this is the Bad part of my story. After the initial shock, I realized that my plan to go to sleep early that night, was going to stay just that - a plan.
I first needed to get the laptop to boot at all. I cycled the laptop power and waited for the GRUB menu to come up, I then used the arrow keys to select the "Single User" kernel configuration, and hit <Enter>. The boot sequence ended up with a password prompt for the root user, I typed it in and then realized that I had no idea what to do next.
I looked at ~/.xsession-errors, but it seemed to belong to an earlier (working) X session. I browsed /var/log/ for a relevant log file and found /var/log/Xorg.0.log - I hoped to see an error or warning message close to the end of the log file that would point me to the cause of the problem. No luck: the log file ended abruptly at some point, with no obvious problem indication.
I then did something irrational:
invoke-rc.d gdm startand to my surprise GDM came up, graphical display and all. WTF?!
I didn't know enough about the startup process to figure out the difference between "Single User" mode and the normal startup sequence. The only obvious difference was visual: a long while ago I added vga=791 to the default kernel command line in /boot/grub/menu.lst - this made the virtual terminals come up in 1024x768 resolution. I did not touch the single user command line, so it came up in the default low resolution (640x480 ?).
So I removed that extra command line parameter, ran update-grub, rebooted, and it "fixed" the problem: apart for the low resolution in the virtual terminal, X came up OK. A happy end?
I guess that most users, at this point, would just settle for a low resolution console, and would go on with their lives, chalking this one up as just another Linux hardware incompatibility issue. I guess I would've done the same, if I didn't know for certain that this was a regression - it worked before, so there's no reason for it to be broken now! I wanted my high resolution console.
After browsing the bugs filed against the ATI display driver at the Debian Bug Tracking System I realized that I was pretty much on my own - my hardware is simply too old, and my setup (Debian GNU/Linux "testing" on a Compaq Presario 900 laptop, with an on-board ATI Radeon Mobility IGP320M U1 video adapter) is probably rather unique.
I was mentally ready to compromise. It seemed very likely that the problem is driver related, so I tried using the VESA display driver instead of the ATI display driver:
- backup /etc/X11/xorg.conf
- open the file for editing
- find the line that starts with Driver in the section named Display
- modify the string on the Driver line from whatever it is to "vesa"
- save the file
- restart X (e.g. by logging out and then hitting <Ctrl>-<Alt>-<Backspace>)
That is, until I tried playing a video file with mplayer - I hit 'f' to go fullscreen, and to my dismay the image was not stretched to fill the screen - instead it was centered, still at the same size, surrounded by a black frame that spanned the rest of the screen area. Apparently, hardware acceleration is used not just for spiffy 3D, but also for image scaling.
Video playback is more important to me than high resolution display in virtual terminals. But I just couldn't let it go. And this is where my story gets Ugly.
To be continued...