BulletProofX

Source
Use Cases

• Annette occasionally gives presentations at work on an old projector, but X fails to start when the projector is connected to her Ubuntu laptop, leaving her at the command prompt. Because of this, she has to move her presentation to someone else's non-Ubuntu laptop, but she'd rather be able to use her own.
• Bob changes his monitor for an older one because his monitor broke. Xorg fails to launch because the monitor fails to work with the frequency configured. Bob want to use the older monitor while his monitor is being repaired.
• Cynthia installs for the first time and everything is properly detected except that the color depth is too high, thus consuming too much memory and preventing X from starting.
• Dustin upgrades his graphics adapter and Xorg fails because of the existing configuration for the previous graphics adapter.

Assumptions

That most failed-to-detect scenarios involve hardware that supports VESA or VGA modes 

Description

This specification describes a new failsafe mode that will be used if X fails to start up. It will be in a reduced (VESA 800x600/256 or VGA 640x480/16) graphics environment running a single application (displayconfig-gtk) for configuring the graphics devices.

The goal of this specification is to eliminate the need for users to need to run apt-get reconfigure on the commandline. That approach is confusing and too technical for many users, so moving away from that will solve a key pain point for users.

This is a failsafe mode for X that will launch if the /etc/X11/xorg.conf file does not result in a working graphical environment due to Xorg failing to start. It can also be invoked manually by specifying 'xforcevesa' via grub's kernel cmdline option, by setting the XORG_FAILSAFE_MODE environment variable to a non-empty string, or by selecting the Failsafe option from the Greeter. 

Implementation

1. Create shell script for gdm to run if the X server crashes
   
   • /etc/gdm/failsafeXServer
2. In /etc/gdm/gdm.conf indicate this failsafe server
   
   • FailsafeXServer=/etc/gdm/failsafeXServer
     
     AlwaysRestartServer=true # Maybe, only if GDM isn't forcing a complete X restart
3. Also provide access to the failsafe session via the greeter
   
   • 
     
     ShowXtermFailsafeSession=true
4. Configure gdm to also invoke the FailsafeXServer script in any of the following cases:
   
   • If the previous X session crashed (i.e., gdm never got the signal back from the X server that it started up).
   • Environment variable XORG_FAILSAFE_MODE is defined
   • /proc/cmdline contains option xforcevesa
   • If the user selects the Failsafe option from the chooser
5. When failsafe mode is activated, check the blacklist for systems we know do not support VESA 800x600/256
   
   • Use EDID + PCI IDs as key to lookup (Can get PCI IDs from discover)
   • If the display does not give EDID info, then use VGA 640x480/16 mode
   • If a matching entry is found, then use VGA 640x480/16 mode
6. Start up the failsafe X session using their regular user account
7. Launch displayconfig-gtk (gnome) or displayconfig (kde) application, under gksu
   
   • Initiate it using an option to let it know we're using it in failsafe mode
   • Make sure to pass along environment variables for hardware preferences
   • Provide welcome screen text explaining why the user is in this mode and what they have to do to solve the issue encountered.
   • Provide a button that allows user to skip configuration and just launch Xorg with the VESA (or VGA) mode.
   • Provide checkbox "Never prompt for reconfiguring"
8. If user chooses to skip configuration, launch X using the temporary failsafe xorg.conf, one time
9. If the user selects the "Never prompt for reconfiguring" option, then set the following in /etc/gdm/gdm.conf:
   
   • FailsafeXServer=

Suggestion

• What about monitors that lie about their capabilities? in such cases the user will just be presented with a 'signal out of range' error, and the X server and GDM are none the wiser. Is there a fallback scenario for that? Since the user cannot see what is going on, there is not a lot they can do, and is highly likely to just reset the machine by power-button or reset button. Perhaps we should detect such an event and present the user with the failsafe X server when a user has not logged on after a reboot and the filesystem has not been unmounted cleanly? I know this seems pretty arbitrary, and it probably is. This is just a brainwave. --HeinPietervanbraam
  • One option could be along the lines of what the Windows bootloader does when it's not able to bring up the GUI:
    1. There would be a certain file, let's call it /var/log/lastX.gdmstartup.
    2. When GDM starts, before trying to bring up X, it would remove the file.
    3. Later, at the first UI action in GDM, the file would be touched.
    4. This would allow a boot-time script to check for the existence of such file. If it does not exist, either X was not correctly displayed (bad sync went undetected, etc) or the computer just rebooted without any login (i.e. power loss). The script would then bring up a curses-based menu offering to enter GUI failsafe mode, console mode, or ignore the error and enter the normal GUI. --Habbit
• There is a tarball available but no details how to do stuff at http://people.ubuntu.com/~bryce/BulletProofX/