BulletProofX

Differences between revisions 19 and 21 (spanning 2 versions)
Revision 19 as of 2007-01-31 10:42:51
Size: 8311
Editor: 82-69-40-219
Comment: update LP URLs; fix for 59618 uploaded
Revision 21 as of 2007-05-17 01:02:36
Size: 15625
Editor: 71
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
##(see the SpecSpec for an explanation)
Line 3: Line 5:
## Register at https://launchpad.net/ubuntu/+specs
* '''Launchpad entry''': https://blueprints.launchpad.net/ubuntu/+spec/bullet-proof-x
 * '''Packages affected''':
 * '''Launchpad Entry''': UbuntuSpec:bullet-proof-x
 * '''Packages affected''': diplayconfig-gtk, xdm,
Line 8: Line 9:
The goal of the bullet proof X specification is to ensure that there is always a way to load the X server, by falling back, automatically or manually, on a working video mode if the default one failed.
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 ==

# TODO
This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented.

It is mandatory.
Line 11: Line 24:
A lot of people are capable of configuring their systems (or getting help to do so) via a graphical interface but don't have a clue when it comes to the command line interface.

== Use cases ==

== Scope ==

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 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.

== 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 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 ==
Line 18: Line 52:
=== How things works, before this spec ===
==== At Grub level ====
"Start Ubuntu in safe graphics mode" option of the LiveCD, make '''xforcevesa''' added to the kernel boot parameters, which is fine for manually choosing safe mode, but not for automatically detecting bad X configuration. The debconf script of xserver-xorg, when executed, sees that "xforcevesa" flag is in use and sets vesa as the default driver.
==== On installing the system ====
==== At each configuration of the server ====
Debconf of xserver-xorg, seems to call dexconf (from x11-common package), to make a new /etc/X11/xorg.conf. In high priority, questions about video modes are asked. Seems like dexconf works quite differently than X -configure in the sense that X -configure need to try to start the X server while dexconf not. Also, dexconf put video modes info in xorg.conf, where X -configure does not. In fact on my computer X -configure make an xorg.conf that fails to find PS/2 mouse, while dexconf do. Yet, I have no idea how dexconf works yet. --Paul Dufresne
==== When Gnome starts ====
[http://www.icims.csl.uiuc.edu/~lheal/doc/gdm/x155.html Some GDM doc]
GDM try to call X. If it fails, FailsafeXServer of gdm.conf is called.
If even that failed, then XKeepsCrashing (by default etc/gdm/XKeepsCrashing) is called.
XKeepsCrashing script will try to use the XKeepsCrashingConfigurators (first of /usr/bin/X11/XF86Setup /usr/bin/X11/Xconfigurator that will works).
==== When Kubuntu starts ====
I can't find an equivalent of gdm's FailsafeXServer for kdm. --Paul Dufresne
==== Each time X is started ====
==== Some applets to change video mode? ====
==== When logging off from a user in GNOME ====
Normally, the X server is reinitialised, but if AlwaysRestartServer=true then gdm will just kill the existing server and start over. See UnresolvedIssues down, to why we may want to set it true.
==== When logging off from a user in Kubuntu ====
The [X-*-Core] section class of kdmrc have the option TerminateServer (false by default),
which if set to true make kdm restart the local X-Server after session exit instead of resetting it. Use this if the X-Server leaks memory or crashes the system on reset attempts.

=== High-Level Design ===
VESA mode 800x600x256 is hereafter called safeMode1.
'Safe Mode' is written on safeMode1 screen.

safeMode1 is triggered in any of the following circumstances:
 * gdm detects that the X server is failing to start (FailsafeXServer)
 * grub have been booted with option safe mode boot (rather than normal boot)

=== Low-Level Design ===

=== Design discussion ===
The configuration fall back process should be:
 * safeMode1, which is sane given the current state of hardware out there, and Windows XP and above also use 800x600 in their safe mode.
   * run dpkg-reconfigure by passing an environment variable
   * xserver-xorg.config should check for an environment variable which behaves the same as xforcevesa
 * If that fails, provide an error on the console.
     * We discussed falling back to vga (safeMode2) instead of just provide an error to the console, but that would introduce another mode switch and delay before the error is shown, and vesa is very well established nowadays.

UI should offer the following options:
  * attempt automatic reconfiguration of video settings
    * can we do this first, and only prompt the user to accept/reject if the auto-config is different from their existing configuration? If yes, they should be prompted to restart in test mode, if no, continue in safe mode.
  * dpkg-reconfigure
  * if that produces a different configuration, allow the sure to test by logging them out and allowing the display manager to restart X
 * give up and use this mode: 'Use these video settings for your normal use'?

 * display diagnostics of what failed - for giving to technical support/showing their local 'computer expert.'

Because it is quite unclear if kdm have some equivalent of gdm's FailsafeXServer script, I say that it is not a good design choice to set safeMode1 by there. I think '''UpStart''' should have a startx event trying to start normally the X server. If X fail to start, then make the XServerFailed event start the safeScreenMode1 job. Later, when the session is started, it would be easy to ask Upstart if safeScreenMode1 job is active, and pop up a window to the user saying that X have not been able to start normally. It is unclear if Upstart is ready for this, but seems like a good test for it. Moreover, it is already one of the goal of [https://blueprints.launchpad.net/ubuntu/+spec/replacement-initscripts replacement-initscripts spec] to be controlled by Upstart ideally for feisty. --Paul Dufresne

I suggest to do like Windows, that is when xserver is reconfigure or configured, the first boot after that, ask the user if he/she should continue to use that video mode, or fallback on safeMode1. (The "Can you read this?" question on Windows) [ System/Preferences/ScreenResolution(translating) already does that, but the new twist is to do it on first boot after xserver-xorg (re)configuration] --Paul Dufresne

The failsafe mode will be initiated by gdm if it fails to start X, or if
an environment variable or commandline 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.
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
 * 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
Line 71: Line 88:
[This section should show how the implementation is different than the design section]


=== Code ===

=== Data preservation and migration ===

== Unresolved issues ==
Until [https://launchpad.net/ubuntu/+source/xorg/+bug/59618 bug #59618] patch is not released, then grub 'Safe mode' won't work. '''[done 2007-01-31]'''

From Forum topic [http://ubuntuforums.org/showthread.php?t=318142]
...sometimes logging out results in a black screen and a system freeze. None of the exit shortcut keys work, and I can't restart X.

I found a very reliable fix to this issue was changing the following line (line 96) in the /etc/gdm/gdm.conf file to this:

 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
    ShowXtermFailsafeSession=true
 4. Configure gdm to also invoke the FailsafeXServer script in any of
    the following cases:
    - If the previous X session crashed
    - 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, 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.

== 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
 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
 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.

== Outstanding Issues ==

 * 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?

 * 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.

 * kdm does not have a gdm-style trigger for going into failsafe mode,
   so such a capability would need to be added.

 * 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.

 * If GDM does not force a complete X restart, the following may need to
   be added to /etc/gdm/gdm.conf:
Line 88: Line 167:
This forces GDM to restart X completely before returning to the login screen...

The [X-*-Core] section class of kdmrc have the option TerminateServer for this. (Paul Dufresne)

I propose to make this into the default configuration in Feisty Fawn.

I now think that previous problem should not be fixed by making AlwaysRestartServer true, but rather by using Upstart to monitor that resetting X server is completed within a reasonable delay (which should depend on the speed of the CPU), and failing to do so, should restart X instead. This would means that the server is broken, and a bug submission should ideally be made if that happens. But up to now, it would have to wait each time we log out, for the reasonable delay, making it worst than AlwaysRestartServer for that broken X server. So that a better design would emit a x-server-broken event with argument watchdog for this. On that event, a always-restart-server-watchdog upstart's job would be started, that would replace the algorithm of this to make the reset-x job to now over do a restart-x job, until the x-server be fixed and send a x-server-been-fixed event :-). Also, it would be good for the reset-x job to compare the memory space occupied from the X-server before and after the script, and emit a x-server-broken event with argument x-memory-leaks that would trigger always-restart-server-memoryleaks job, which would be identical to always-restart-server-watchdog, except offering to send a different bug report. --Paul Dufresne

Future work:
 * Fall back for thin clients
 * Kubuntu
Line 101: Line 168:

Bulletproof-X

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.
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.

Fallback Use Cases:
 * 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.
 * Ann changes her VGA for a new one. Xorg fails to start.
 * John upgrades his graphics adapter and Xorg fails because of an existing configuration for the previous graphics adapter.
 * Amy installs for the first time and everything is properly detected except color depth is too high, thus consuming too much memory and preventing X from starting

Use Cases for problem areas:
* Install-time - x not detecting correctly
* Update-time - x breaking during updates

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.

The debconfage is going away. Current xorg in debian-unstable has removed the need for Modules and Fonts, rest is on the horizon.

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.

Guadalinux does extensive testing of their ubuntu-based installs, so if we can tie our efforts in with their schedule they could test the rollout of it. Already have >400,000 users in 1100 schools. They're having small updates almost once a day. They do testing from June-September (May to October). HW varies - i965, i945, i815 typically. Rage and nvidia on a few laptops. Currently they have few problems with monitor resolution detection (xserver-xorg-video-intel 2.0 did not make it to 7.04, but 1.9.94 is in universe). Since they have a controlled environment, we probably should have few issues and should be pretty easy to validate.

A major pre-requisite for this is to get the driver xrandr support in all the drivers. radeon support was added last night; nouveau we can expect to have xrandr before too long.
dnusinow said on #debian-x last night:
02:38 < gravity> I need to add one more feature for my module defaults patch upstream, and I also need to figure out exactly how to get rid of discover
02:39 < gravity> I don't really understand how the server figures out which driver to load when there's no xorg.conf yet
02:43 < gravity> The other thing that the xserver postinst depends on is xresprobe. I haven't decided if I want to get rid of it yet.
02:44 < gravity> randr1.2 depends on having DDC info available. If the monitor doesn't send that, then xresprobe could tell the postinst that the DDC info is missing so that the postinst can write some default values to xorg.conf
02:45 < gravity> On the other hand, the server should probably just fill in some default values itself. I don't know if it does that yet.
02:45 < gravity> If so, we can dump xresprobe as well.
02:45 < gravity> At which point we just wait for all the drivers to get randr1.2 support and for input hotplugging to land. Then our job becomes significantly easier
02:48 < bgoglin> just wait a couple years then :)
02:51 < gravity> hehe
02:51 < gravity> Realistically, it's already here. Just don't give people a choice in the debconfage, let the server just look in /dev/input/mice, and load kbd and mouse, and we cover 99% of the use cases
02:52 < gravity> Anyone who wants something weirder can just write their own conf :-)
02:52 < bgoglin> :)

Technical design for bulletproof-x

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.

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.

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.

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.

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 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.

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.

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.

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

VESA 800x600x256 is guaranteed by MS Windows logo requirements.

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.

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: diplayconfig-gtk, xdm,

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

# TODO This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented.

It is mandatory.

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 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.

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 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

Design

The failsafe mode will be initiated by gdm if it fails to start X, or if an environment variable or commandline 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. 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
  • 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 - 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, 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.

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
  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
  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.

Outstanding Issues

  • 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?
  • 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.
  • kdm does not have a gdm-style trigger for going into failsafe mode,
    • so such a capability would need to be added.
  • 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.
  • If GDM does not force a complete X restart, the following may need to

BoF agenda and discussion

Bulletproof-X

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. 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.

Fallback Use Cases:

  • 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.
  • Ann changes her VGA for a new one. Xorg fails to start.
  • John upgrades his graphics adapter and Xorg fails because of an existing configuration for the previous graphics adapter.
  • Amy installs for the first time and everything is properly detected except color depth is too high, thus consuming too much memory and preventing X from starting

Use Cases for problem areas: * Install-time - x not detecting correctly * Update-time - x breaking during updates

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.

The debconfage is going away. Current xorg in debian-unstable has removed the need for Modules and Fonts, rest is on the horizon.

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.

Guadalinux does extensive testing of their ubuntu-based installs, so if we can tie our efforts in with their schedule they could test the rollout of it. Already have >400,000 users in 1100 schools. They're having small updates almost once a day. They do testing from June-September (May to October). HW varies - i965, i945, i815 typically. Rage and nvidia on a few laptops. Currently they have few problems with monitor resolution detection (xserver-xorg-video-intel 2.0 did not make it to 7.04, but 1.9.94 is in universe). Since they have a controlled environment, we probably should have few issues and should be pretty easy to validate.

A major pre-requisite for this is to get the driver xrandr support in all the drivers. radeon support was added last night; nouveau we can expect to have xrandr before too long. dnusinow said on #debian-x last night: 02:38 < gravity> I need to add one more feature for my module defaults patch upstream, and I also need to figure out exactly how to get rid of discover 02:39 < gravity> I don't really understand how the server figures out which driver to load when there's no xorg.conf yet 02:43 < gravity> The other thing that the xserver postinst depends on is xresprobe. I haven't decided if I want to get rid of it yet. 02:44 < gravity> randr1.2 depends on having DDC info available. If the monitor doesn't send that, then xresprobe could tell the postinst that the DDC info is missing so that the postinst can write some default values to xorg.conf 02:45 < gravity> On the other hand, the server should probably just fill in some default values itself. I don't know if it does that yet. 02:45 < gravity> If so, we can dump xresprobe as well. 02:45 < gravity> At which point we just wait for all the drivers to get randr1.2 support and for input hotplugging to land. Then our job becomes significantly easier 02:48 < bgoglin> just wait a couple years then Smile :) 02:51 < gravity> hehe 02:51 < gravity> Realistically, it's already here. Just don't give people a choice in the debconfage, let the server just look in /dev/input/mice, and load kbd and mouse, and we cover 99% of the use cases 02:52 < gravity> Anyone who wants something weirder can just write their own conf Smile :-) 02:52 < bgoglin> Smile :)

Technical design for bulletproof-x

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.

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.

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.

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.

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 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.

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.

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.

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

VESA 800x600x256 is guaranteed by MS Windows logo requirements.

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.


CategorySpec

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