Look into feasibility of using an alternatives system rather than diversions

Good day Mario,

I've just uploaded a new 8.543 version of -fglrx to Intrepid which now should work with xserver 1.5. Would you mind testing this new version and reporting back whether this issue is still present? If it is, it would be helpful if you could (re-)post your Xorg.0.log from running with this version. Thanks ahead of time.

If you don't have Intrepid installed on your system, you can test this by booting an Intrepid LiveCD (available from cdimage.ubuntu.com), using either the -vesa or -ati driver, then update to the latest version of Ubuntu, install fglrx, and then logout and back in. Your /var/log/Xorg.0.log will confirm whether you've loaded FGLRX successfully.

If you find any new issues, please report them as separate bugs. You can use the tool `ubuntu-bug fglrx-installer` which will gather the necessary files and create the launchpad report for you to fill in more easily.

Nevermind the last comment. :-)

Might I add the use-cae of switchable graphics.
I have a Thinkpad T400 with both Intel and Radeon chipsets.
An alternatives system will allow easy alternating between chipsets.

I have an ancient laptop where, of all things, the 3D-part of the graphics card is broken. No really, it's a hardware defect.
Being able to have a system with alternatives would be great as I could continue to use the 2D-driver, but always use software OpenGL instead of it being broken. (Even though it's currently a printer-server for the wireless network)...

Looking forward a few months, I'd like to not have this bug open after Lucid. I think we need to come to a decision on it and either implement it for the LTS, or else decide to stay with the current system and close this bug.

This would be a pretty significant change, so might be a bit ambitious for an LTS (really, I guess we should have done it in karmic, but way too late now) but the benefit in terms of making it easier for users to switch between drivers could well be worth it. I think doing this post-LL would be detrimental since it would inhibit being able to backport patches, drivers, etc. to the LTS, so if we do not implement it for LL I think we should just decide not to do it (at least, not until the next LTS-1).

I'm not 100% certain how to undertake this change, as it is a touch beyond my packaging-fu, but Mario I assume you'll be at the UDS in Dallas? Would you like to work out an implementation plan for it there?