XorgAutoconfiguration

X.org Autoconfiguration

Status

Introduction

Simplify and improve the robustness of the Ubuntu X autoconfiguration system

Rationale

The current X.Org configuration mechanism is not good. It was heavily derived from Debian's XFree86 configuration, which has very little autoconfiguration infrastructure and has since had full autoconfiguration totally bolted on to it. It requires many hacks and special cases, and barely hangs together. It is exceptionally fragile, and often breaks unexpectedly.

There is also no scope for a 'safe mode': we should detect if X failed to start, and then be able to generate a safe configuration (e.g. vesa, vga) so we can always get a display up, even if it is slightly suboptimal.

It is also infrastructurally bound to the simple use case of one keyboard, one mouse, and one output device. Multi-head configurations are becoming more common as most, if not all, consumer cards now ship with this capability, and multi-seat configuration is extremely desirable. Multi-head configuration is currently not handled at all, and multi-seat is handled by having a separate package which copies large swathes of xserver-xorg's postinst and changing the configuration behind its back.

We are also bound to discover1, which is a poor codebase and very much surplus to our requirements. Currently, only the data set (which is maintained by DanielStone, who periodically adds every new video card he can find), is outwardly useful to us. To this end, we should hopefully ditch discover1, however the overhead of moving the dataset to another format is seriously non-trivial.

Scope and Use Cases

  • Ask all questions in stage 1 (of the install) if possible.
  • Provide the user with an opportunity to redetect hardware if X startup fails, or preferably just do it for them.

  • Implement a "safe mode" fallback configuration to provide a minimal X-based GUI with very few assumptions that works everywhere.

  • Eliminate discover1 in favour of something simpler, in hopes of sharing the database with other projects (especially X.Org upstream).

  • Multi-head configuration.
  • Solid multi-seat configuration.

  • Integrate standard Ubuntu configuration tool with LTSP configuration (see LTSPXorgConfiguration).

Implementation Plan

  • Possibly throw existing shell script mess away and start again, writing in Python.

  • Take LTSP's needs into account in xserver-xorg and xresprobe configuration (see LTSPXorgConfiguration).

  • Rewrite discover1 (already done in ~100 lines of Python).

  • Implement safe mode fallback.
    • The first time we fail, re-run configuration in the first safe mode, which will use vesa with a conservative resolution. Write this out to /tmp somewhere, and start X up with a small dialog informing the user of what has happened. Offer to overwrite their current configuration with this, and if they accept, save the old configuration somewhere and move the vesa configuration in.
      • Should we integrate this with hwdb, and offer to automatically generate a bug report template?
    • If the configuration above fails, do the same thing, but use vga or fbdev (as platform-appropriate) at 640x480@60Hz. If this doesn't work, the hardware should not be being sold.
  • Add support for multiple heads.
    • To some extent, this is not possible when doing automatically; due to the limitations of VESA, we can only probe one head. Investigate the concept of splitting drivers out to shared libraries and wrappers around that upstream, so both Xorg and ddcprobe can use librardeon, for example.
    • Work out whether Xinerama or MergedFB is more appropriate, per hardware.

      • Xinerama does not allow you to do 3D/video acceleration on both heads. Some drivers implement 'MergedFB', which allows you to use 3D and video on both heads. Currently the radeon and sis drivers do this; i810 may do it, and the nVidia binary driver has a similar option called 'TwinView'.

  • Add multiseat support (multiple users on the same machine -- each using a different keyboard/mouse/monitor combination).
    • This is currently provided by the multiseat package, which is a gigantic hack. It copies large swathes of the original xserver-xorg.postinst, and does not support multiple cards from different vendors, etc. Multiseat support needs to be present within the original xserver-xorg.postinst, not hacked around.

Data Preservation and Migration

Don't overwrite custom xorg.confs if they exist when upgrading; mostly identical to the current system.

Packages Affected

  • xorg

  • xresprobe

  • multiseat

User Interface Requirements

Very few. Ideally users should not have to interact with this tool.

Outstanding Issues

How do we probe multiple heads/cards/etc? VBE (VESA BIOS Extensions) does not give us a choice: only the primary head on the primary card. Need to investigate things such as libradeon (see above).

UDU BoF Agenda

  • Infrastructure changes
    • Maintainer script redesign in Python?
  • Reconfiguration
    • Detecting failure
    • Detecting whether the user is using an autogenerated configuration or a hand-edited configuration, act appropriately
    • Advise user to report a bug if our newly-generated config matches the old one?
    • i18n/l10n
  • Safe mode
    • Framebuffer should be available for USplash
    • Even without framebuffer, Xorg does a pretty good job detecting without our help
    • VGA? VESA?
    • Can we detect the case where X hung the system on the previous boot, and fall back?
      • this doesn't happen very often; far more common is the case where X works fine, but the monitor doesn't display anything, and we can't really detect this
    • How to get back to non-safe mode?
  • Video device database

    • Don't want discover1

    • Want to be able to share data with upstream and other projects
    • Integrate with hardware database

UbuntuDownUnder/BOFs/XorgAutoconfiguration (last edited 2008-08-06 16:36:24 by localhost)