uninstalling fglrx results in unknown bad state

[floid]

Dropped in a Diamond-branded Radeon 6450 card today to work around LP #1181355 - the default open-source Xorg radeon driver was working flawlessly until I switched to fglrx-updates and then attempted to switch back, all through the settings UI.

Possibly I made the mistake of running aticonfig while testing - but same is a prerequisite to use the ATI/AMD utilities to peek at the card's temperature and clocks. (Trivia: The open-source driver does appear to run the card's RAM at 800MHz by default, or at least reports that it does, but this was causing no problems.)

In any case, reselecting the Xorg driver after fglrx has been used appears to proceed without complaint, but rebooting then results in either only a purple screen or a 'wrapped screen' bug similar to that described in https://bugzilla.redhat.com/show_bug.cgi?id=827895#c23 - including 'shifted' vtys - that does not change after mode-flipping with Xrandr from a remote session - although modes other than the default 1920x1080 for the monitor are likely to be white, flashing, or full of colored cruft.

(However, Unity doesn't appear to take input and whichever component is responsible for nagging for a keyring password doesn't appear to launch until after the mode is flipped to something else and back, so that's still a way to jiggle things enough to be able to interact with the Xorg session at all.)

When the card comes up too confused to display more than a purple screen or blank vtys, the xrandr trick doesn't work enough to get that far.

Still trying to figure out exactly what has happened here, but filing against software-properties-gtk as that is the component making the 'guarantee' to the user that things should return to a known state when the option is selected.

In retrospect I think I may have been bitten by this on other systems and simply left them running fglrx, so it may have been around for a while.

Expected behavior: Reselecting Xorg driver should work as well as it did prior to trying out fglrx when installed via the same UI.

What happened instead: Stuck with troubleshooting what could possibly have changed to cause the 'permanent' breakage obeserved and/or with fglrx.

I'd love to extract some useful telemetry from the affected machine but it's a bit annoying to interact with in the broken state [and at this exact moment someone is using it for work so it is inaccessible to re-break] - figured I would file fast and add detail later just in case this is a known issue with a known but hard-to-Google-for workaround.

[floid (jkanowitz)]

Well, that's a simpler description and the detail's in the comment anyway, but I had no way of knowing if the GUI approach might be touching anything in the 'alternatives' system or thereabouts different from direct apt manipulation.

Let me know if there's anything I can do to assist in solving, maybe I can see if this is reproducible from liveUSB where it wouldn't be hard to write a stick and get back to the "Xorg radeon driver actually works fine until you try something else" state.