Although the combination of drm/radeon, the X.org radeon module and newer Mesa drivers (now using 7.7 RC 2) is pretty much stable for me at the moment, I keep hitting what probably is a bug in the synaptics touchpad driver (X.org), which I recently updated while following other new packages in the Debian testing distribution (currently Squeeze) — the X server occasionally locks up when restarting via kdm (KDE's login and display manager) and the last bits in the logs indicate that it's trying to process the input device configuration; plus, the busy 'X' cursor appears on the screen before it gets locked up. Again, pressing the system's ACPI power-down button helps and I don't need to resort to “emergency” reboots.
Besides that little annoyance, there's the infamous BSS I mentioned in earlier iterations of this story. However, I have found a tricky solution to this dreaded disease with a non-KMS configuration.
Basically, I must first get to a text-mode console (read: text-mode, not a graphics framebuffer console, although I suppose it could work as well) and save the graphics hardware state for later with vbetool as root:
# vbetool vbestate save > ~/textmode_vbestate
Then I create an appropriately named set of screen sessions as my normal user from a text-mode console; say,
screen -S radeonfix, and don't detach it from the terminal. Later, when radeon finally screws up, I reattach from a terminal emulator under X using
screen -x radeonfix (where
-x is for attaching to the session without detaching it from the real text-mode console, which we'll need) and type the magic words, but do NOT run the last command as it could harm X.org or the hardware in some way:
$ su # vbetool vbestate restore < ~/textmode_vbestate
Then I switch back to the console (which is under the effects of BSS by now) that has the same screen session attached and blindly press Enter. Voilà! I get a “Function not supported” warning but it still restores the text-mode console to normality without having to restart the whole system. However, the X.org radeon module is trying to be too smart and causes BSS again after I switch back and out of X. This seems to happen because it's attempting to do a similar function with its own copy of the hardware state, unfortunately captured after breaking the consoles. The solution? Kill and restart X right after using vbetool to fix the text-mode consoles and before switching back to X (or otherwise you won't be able to see the command you're typing to restart X) — this way radeon starts fresh and grabs a copy of the good hardware state.
It's probably not necessary to grab the hardware state with vbetool upon every boot, as long as it is compatible. I have successfully used an old captured state with the same console settings.
If I had a separate machine from which I could connect to the laptop, I'd be able to attach in multi-display mode to the screen session using SSH, but since I don't, I have to do this unelegant maneuver with a running X. And if there's no X running, well, crap. Fortunately the BSS is fairly inoffensive otherwise, and console applications will still receive input events normally, including the CTRL+ALT+DEL sequence and the machine's ACPI power-down button.
Note that the aforementioned theory may also serve as basis to explain why radeon + KMS causes immediate BSS for me. Let me think:
Firstly, X.org starts up, radeon loads the kernel's drm and radeon modules, they take over the text consoles using a special KMS-based framebuffer driver as soon as I switch away from X. But radeon (the X.org driver) keeps a copy of the hardware state taken at X's startup, when there was no framebuffer driver managing the consoles, so it has the state of the controller in text mode. Later, when I switch to a text terminal from X for the second time, the X.org driver switches the controller to the text mode state. Oops! That won't work very well with a framebuffer (read: graphics mode) console driver, he he! So the theoretical solutions are:
- Make drm/radeon part of the kernel image in the build configuration; or
- Insert drm/radeon when running
/etc/rc.local, that is, before X starts.
I could easily try these but I'm currently enjoying this basic accelerated 3D rendering, which I guess — just like XRender acceleration — won't work with KMS. I've also heard rumors that ATI R6xx/R7xx KMS and hibernation are not a perfect combination yet, so I'd better keep away from it for now, lest my files literally go to hell.