More On Ubuntu's BulletProofX
Early this morning we published an article on Ubuntu's BulletProofX taking a simpler approach for its fail-safe mode when the X Server fails to properly start. No longer is the user bound to displayconfig-gtk but there is a menu system with options for diagnosing the problem and reconfiguring the xorg.conf. However, since that article went live we have a few more details on this revision to BulletProofX.
In fact, the FailSafeXServer has picked up another feature. When troubleshooting the X server is now an option to save the relevant configuration and log files. These files important for diagnostic purposes are saved to a .tar archive within /var/log/, which makes it easy and convenient for the new user to find the relevant files needed when submitting a bug report. The patch written by yours truly will appear in the next x11-common update for Ubuntu 8.10.
Canonical's Bryce Harrington who is largely responsible for BulletProofX and X.Org in Ubuntu had provided some comments on these fail-safe X changes.
Look for this new work in Ubuntu 8.10. A lot of people will sure be running into the FailSafeXServer if AMD doesn't deliver X Server 1.5 support next month in their Catalyst 8.10 Linux driver.
In fact, the FailSafeXServer has picked up another feature. When troubleshooting the X server is now an option to save the relevant configuration and log files. These files important for diagnostic purposes are saved to a .tar archive within /var/log/, which makes it easy and convenient for the new user to find the relevant files needed when submitting a bug report. The patch written by yours truly will appear in the next x11-common update for Ubuntu 8.10.
Canonical's Bryce Harrington who is largely responsible for BulletProofX and X.Org in Ubuntu had provided some comments on these fail-safe X changes.
I liked displayconfig-gtk, but the class of problems (monitor configuration) it solved are no longer issues for most people. Some people have been advocating fixing up displayconfig-gtk or replicating it with a different backend, but I thought it would be better to go back to first principles, and design something new around the specific failure use cases people are really running into.
I also wanted to keep it very simple implementationally, so it's easy to test and easy for people to patch. Also I want to think of it less as a tool, and more as a toolbox, so it's easier to switch in/out tools as needed in the future.
Look for this new work in Ubuntu 8.10. A lot of people will sure be running into the FailSafeXServer if AMD doesn't deliver X Server 1.5 support next month in their Catalyst 8.10 Linux driver.
2 Comments