BulletProofX

Differences between revisions 26 and 27
Revision 26 as of 2007-05-31 05:33:50
Size: 15169
Editor: 71
Comment:
Revision 27 as of 2007-05-31 17:35:56
Size: 12935
Editor: 71
Comment:
Deletions are marked like this. Additions are marked like this.
Line 38: Line 38:
The failsafe mode will be initiated by gdm if it fails to start X, or if
an environment variable or command-line option is passed in. This should
also permit forcing vesa mode via the boot parameters.
The failsafe mode will be initiated by gdm if it fails to start X, or if an environment variable or command-line option is passed in. This should also permit forcing vesa mode via the boot parameters.
Line 42: Line 40:
Failsafe mode runs with administrative permissions since it will likely
need to alter the user's xorg.conf. Because of this, the user will need
to authenticate. However, care must be taken to ensure the user notices
that this is an abnormal situation; the authentication request must not
be confused with the standard login screen.
Failsafe mode runs with administrative permissions since it will likely need to alter the user's xorg.conf. Because of this, the user will need to authenticate. However, care must be taken to ensure the user notices that this is an abnormal situation; the authentication request must not be confused with the standard login screen.
Line 48: Line 42:
In this mode, the current xorg.conf will be ignored; instead a VESA
800x600/256 configuration will be used. In some (rare) cases, hardware
may not support VESA, in which case a VGA/16 mode will be the fallback.
These cases will be tracked by means of a blacklist file.
In this mode, the current xorg.conf will be ignored; instead a VESA 800x600/256 configuration will be used. In some (rare) cases, hardware may not support VESA, in which case a VGA/16 mode will be the fallback, or framebuffer if that won't work either.  These cases will be tracked by means of a blacklist file.
Line 53: Line 44:
When launched into failsafe mode, a single application will be presented
to the user: gtk-displayconfig. A window manager will be needed since
gtk-displayconfig has some popup dialogs, but even a simple window
manager should suffice. This application will provide several
functionalities:
When launched into failsafe mode, a single application will be presented to the user: gtk-displayconfig. A window manager will be needed since gtk-displayconfig has some popup dialogs, but even a simple window manager should suffice. This application will provide several functionalities:
Line 63: Line 50:
   * i18n / translatable
Line 88: Line 76:
    * If a matching entry is found, then use VGA 640x480/16 mode     * If a matching entry is found, or if the monitor doesn't give EDID info, then use VGA 640x480/16 mode
Line 95: Line 83:

 * Whitelist for determining when to use xrandr
 * Whitelist for determining when to use Compiz
For whitelist, build onto discover-data, using pci ID's and falling back to the model name.
Line 119: Line 111:

 * Test R500 / Radeon X1300 - X1950 hardware - this has had problems with vesa mode in the past, but a patch exists to fix it. Since this is a common kind of hardware, especially for laptops, we need to ensure this patch is included in Gutsy.

What if the user has thrashed up their system by messing up e.g. glx drivers, have a wrong nvidia driver in the kernel, or etc. Will this vesa mode be able to be loaded.
Line 150: Line 146:
Fallback: try first Vesa, then VGA 640x480x16, then Framebuffer. if fallback mode is activated, launch displayconfig-gtk.

<sebas> Keith Packard said that the 'safest mode' is 800x600/16 since that's what's used by Windows default (and thus tested for really every graphics chip.

fallback to vesa - failsafe. Supposed to work 100%, but some hardware. Or fallback to 256 or 16 vga if that doesn't work. Create blacklist for cards that vesa fails on (like R500). May have to provide a grub boot option.
Line 162: Line 153:
The debconfage is going away. Current xorg in debian-unstable has removed the need for Modules and Fonts, rest is on the horizon.
Line 170: Line 159:
A case for this would be if the user upgrades their graphics card, and wants it to work without editing xorg.conf, etc. Getting rid of Device-section is the next goal for debian. If the device in the old conf doesn't work, fallback using what the server would use automatically. If the device in the old conf doesn't work, fallback using what the server would use automatically.
Line 174: Line 163:
Probably the fewer fallback modes, the better, even if the fallback modes are less capable than they could be, since then to support the user there'll just be one state they will be starting from, so it'll be simpler to walk them through it, and since they (ideally) won't be in that mode normally.

In fallback mode, it would run with a single application (displayconfig-gtk). We'll need a simple window manager since it has a few popup dialogs for selecting drivers, etc.
Line 179: Line 164:

Also will need to have an override way to force it into or out of this mode (maybe a commandline option or something?) for validation testing. Or instead have it simply log a failure but skip going into the mode.

Will also need a help file to explain being in fallback mode + how to get out. Ideally, this should be i18nable as well. We'll need to doublecheck that displayconfig-gtk is able to include this.

How about a mechanism to allow getting into a failsafe mode with a working Firefox webbrowser so they can search the net to find out how to fix the problem?

VESA 800x600x256 is required by the Window logo problem. So we may as well accept that as the default for our failsafe mode. For monitors without EDID, maybe we'll need to go down to 640x480.
Line 192: Line 169:
We might want to just extract the data from 'discover' rather than carry discover as a full dependency if its pci-id list is the only thing needed.
Line 196: Line 171:
What if the user has thrashed up their system by messing up e.g. glx drivers, have a wrong nvidia driver in the kernel, or etc. Will this vesa mode be able to be loaded.

VESA failure is seemingly a very big thing w/feisty since Radeon X1300 - X1950 series is so common nowadays on laptops etc. Sounds like a good thing to blacklist.

<tepsipakki> r5xx vesa failure is a bug with a fix. There should be no need for a white/blacklist.

If worse comes to worse and the display won't work at all with default drivers, what about a text tool to prompt user about downloading the proprietary drivers and installing them.

We will need a white list (black list?) to determine when to default to the new xrandr and/or compiz, and when to just use the current system
We might want to just extract the data from 'discover' rather than carry discover as a full dependency if its pci-id list is the only thing needed.
Line 208: Line 175:
For whitelist, build onto discover-data, using pci ID's and falling back to the model name.

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

  • Launchpad Entry: bullet-proof-x

  • Packages affected: displayconfig-gtk, gdm, Xorg

Summary

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

Release Note

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 an X crash. 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.

Rationale

Xorg sometimes fails to launch for some users, typically due to failure to detect hardware properly during installation or when the user has changed monitors or graphics cards.

Currently Ubuntu support has the user re-run dpkg-reconfigure, but this is confusing and too technical for many users, who complain about this. So the sooner we can move away from requiring that, the better.

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 'new' (the older one) 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 an existing configuration for the previous graphics adapter.

Assumptions

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

Design

The failsafe mode will be initiated by gdm if it fails to start X, or if an environment variable or command-line option is passed in. This should also permit forcing vesa mode via the boot parameters.

Failsafe mode runs with administrative permissions since it will likely need to alter the user's xorg.conf. Because of this, the user will need to authenticate. However, care must be taken to ensure the user notices that this is an abnormal situation; the authentication request must not be confused with the standard login screen.

In this mode, the current xorg.conf will be ignored; instead a VESA 800x600/256 configuration will be used. In some (rare) cases, hardware may not support VESA, in which case a VGA/16 mode will be the fallback, or framebuffer if that won't work either. These cases will be tracked by means of a blacklist file.

When launched into failsafe mode, a single application will be presented to the user: gtk-displayconfig. A window manager will be needed since gtk-displayconfig has some popup dialogs, but even a simple window manager should suffice. This application will provide several functionalities:

  • Help screen
    • Explain why we're in failsafe mode
    • Synopsis of how to use gtk-displayconfig to get out of this mode
    • Where to get further information
    • i18n / translatable
  • Skip configuration (Just run X in reduced (VESA) mode)
    • [ ] Never prompt for reconfiguring
  • Specify graphics card, monitor, and driver(s)
  • Select resolution and refresh rate
  • Write out xorg.conf with new changes
    • Use temporarily (just this session)
    • Use as the permanent default

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
  3. Also provide access to the failsafe session via the greeter
  4. Configure gdm to also invoke the FailsafeXServer script in any of the following cases:
    • If the previous X session crashed
      • ... but not if it was terminated using Ctrl-Alt-Backspace or whatever. Does this really mean "if gdm never got the signal back from the X server that it managed to start up"? --ColinWatson

    • 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 + lspci as key to lookup
    • If a matching entry is found, or if the monitor doesn't give EDID info, then use VGA 640x480/16 mode
  6. Start up the failsafe X session
  7. Launch displayconfig-gtk application
  8. Display a welcome screen explaining why the user is in this mode and what they have to do to solve the issue encountered.
  9. Provide a button that allows user to skip configuration and just launch Xorg with the VESA (or VGA) mode.
  10. If the user selects the "Never prompt for reconfiguring" option, then set the following in /etc/gdm/gdm.conf:
    • FailsafeXServer=
  11. Whitelist for determining when to use xrandr
  12. Whitelist for determining when to use Compiz

For whitelist, build onto discover-data, using pci ID's and falling back to the model name.

  • What about Kubuntu? Since displayconfig-gtk is a port from KDE, I figure it shouldn't be too hard to support that too. --ColinWatson

Test/Demo Plan

  1. Install Failsafe X package for testing
  2. Reboot and use each available mechanism to force failsafe mode
    • Set environment variable
    • Option specified in /proc/cmdline
    • Failsafe mode selected from chooser
      • Also test deliberately misconfiguring X such that it fails to start, since this is the most important case. --ColinWatson

  3. Check that the /etc/X11/xorg.conf file is not being used
  4. Verify screen comes up as 800x600/256
  5. Verify mouse and keyboard work properly
    • ... and that the keyboard layout is the same as before. --ColinWatson

  6. Verify GUI config tool is running
  7. Check that help text and interface is internationalized appropriately
  8. Check if displayconfig-gtk identifies the hardware correctly and selects the correct driver
  9. Verify the GUI provides the correct listing of resolutions and refresh rates for the selected configuration
  10. Verify that the system can drop to lower resolutions such as 640x480.
  11. Verify that the system can go to the maximum resolution supported by the hardware
  12. Verify that the xorg.conf is written with the options selected through the GUI

Rerun the test with different language settings, selecting different resolutions, and selecting incorrect driver/hardware combinations.

  • Test R500 / Radeon X1300 - X1950 hardware - this has had problems with vesa mode in the past, but a patch exists to fix it. Since this is a common kind of hardware, especially for laptops, we need to ensure this patch is included in Gutsy.

What if the user has thrashed up their system by messing up e.g. glx drivers, have a wrong nvidia driver in the kernel, or etc. Will this vesa mode be able to be loaded.

Outstanding Issues

These need to be resolved, or at least explicitly deferred to a later phase, before the spec can be approved. --ColinWatson

  • Which window manager to use for the failsafe mode?
  • If the user is required to authenticate to use the configuration tool, will this cause added complexity/confusion for the user?
    • How about just gksu's normal authentication dialog? --ColinWatson

  • When writing out xorg.conf, it must preserve any data that existed beforehand. Ideally, it must preserve formatting of this data as well, so diffs will show only meaningful lines changed.
    • This seems like a note to the implementor that can go in the implementation section. See also my comment in the test plan above. --ColinWatson

  • kdm does not have a gdm-style trigger for going into failsafe mode, so such a capability would need to be added.
    • Again, this is something to put in the implementation section. --ColinWatson

  • Does xrandr have a mechanism for exporting the config, so we can apply changes immediately?
    • May need to write some tools to run xrandr to read this
    • There isn't a tool for writing the changes, but that should be a small tool to make
  • If resolution of the failed X configuration requires specification of xorg.conf Options, the user will still need to manually add these, because gtk-displayconfig does not currently provide a list of available Options to select from.
    • Do we think this is widespread? Is it worth specifying that we need to add this to gtk-displayconfig? --ColinWatson

  • If GDM does not force a complete X restart, the following may need to be added to /etc/gdm/gdm.conf:

BoF agenda and discussion

Has this all been factored into the main specification? The spec can't be approved until that's done. It's OK to leave things here as historical context if that's useful; but things that have been written up clearly should be removed from this section. --ColinWatson

An X crashing should revert back to a known-good Blacklist not a terribly good idea, since it isn't future-proof at all. True but the vesa failure is quite likely a very rare issue, and a whitelist would be even worse. VESA failure is seemingly a very big thing w/feisty since Radeon X1300 - X1950 series is so common nowadays on laptops etc. Sounds like a good thing to blacklist. <tepsipakki> r5xx vesa failure is a bug with a fix. There should be no need for a white/blacklist.

Currently ubuntu support has the user re-run apt-get reconfigure, but this is confusing and too technical for many users, who complain about this. So the sooner we can move away from requiring that, the better.

We will need to replace the current install infrastructure with new one using the xrandr and pci-id list approach... We may need to continue with the current xresprobe/ddcprobe stuff for ISA or older systems, but for most known audience we can expect the xrandr approach to be workable.

Marc Tardif is working on some things to work around these problems, so if gutsy will be fixing this in the coming few months it could save him some time. We probably need to get synced up.

xforcevesa should stay, but we should implement this at a closer level, perhaps with an x startup script that checks your hardware against the blacklist, and then switch to vesa mode. Does a pcid check.

If the device in the old conf doesn't work, fallback using what the server would use automatically.

In some cases the color range is mis-detected, preventing xorg to load. Perhaps here we need to detect the amount of video ram available to verify the color depth. Log files report this specific error and may be used to trigger fallback.

During fallback mode, should we have a user login or just automatically log them in? Probably have them end up in their regular login, then they can sudo to run setup programs. This should also provide a small subset of the tools - displayconfig-gtk, restricted driver manager?, (probably not synaptic or terminals...) Button to override and go to login anyway, but also hooks to force / help hardware config scenarios where automation is required.

Also include option "this is good enough" so user can just stick with the generic vesa mode without having to continually go through the failsafe mode first.

What about on the live CD? It allows for selecting to go to a failsafe mode. In a live-cd failure it should go directly to the failsafe mode without requiring any configuration step.

LiveCD: if the user has to configure anything on the livecd, then we've failed. So if X fails, go straight to the fallback.

We might want to just extract the data from 'discover' rather than carry discover as a full dependency if its pci-id list is the only thing needed.

For projectors that don't support EDID, assume it can do 800x600 (maybe 640x480). Make it easy to change it after. The xrandr tool spits out a list of known modes. The GUI tool should be able to tell that the projector does or does not support EDID, and if not it should give the list of possible modes.


CategorySpec

BulletProofX (last edited 2008-08-06 16:35:43 by localhost)