ScreenConfigurationUI

Summary

A replacement for the deprecated displayconfig-gtk for configuring xorg.conf settings. This tool should include 3 different profiles: 1) a simplified (graphical) interface for Bulletproof X (to set driver, custom resolution and refresh rate, with no support for multiple screen layouts) based on X-Kit; 2) an advanced RandR 1.2 aware UI based on a common Python RandR API (so that it can be used with both GTK and QT4, etc.); 3) an ncurses or console based text-mode tool providing equivalent functionality as in #1.

Release Note

Ubuntu now provides additional tools for configuring your X session, including simplified versions of the tool for handling reconfiguration under various error conditions.

Rationale

Long ago, X needed to be manually configured. Various tools existed to automate these steps during installation, however they were often incorrect. By and large most users needed to be comfortable fiddling with the xorg.conf to get a proper display with correct resolutions, font sizes, and input devices.

The switch to monitor-hotplug (aka XRandR) and input-hotplug largely put an end to the X configuration ordeal. The vast bulk of hardware could be detected and automatically configured on the fly. For situations where that didn't work, the libxrandr protocol enabled runtime tools (such as the Screen Resolution tool we currently ship) to redo configuration settings dynamically.

In theory, that should have solved the problem completely.

In practice, though, things have proven to be not so simple. While hotplug works in, say, 95% of the time, there are still some corner cases where it does not. Monitors with invalid EDID; Old pre-EDID monitors; KVMs that fail to pass EDID info along correctly; Server or driver bugs; Proprietary video drivers; and so on. Some of these are easily solved with quirks, or less easily solved with bug fixes; but in the meantime the user could be left with a broken system. In a few cases there really is no solution, and it must be configured in xorg.conf.

We have been moving more and more towards an empty xorg.conf situation, which is quite suitable for the 95% cases, but ironically it actually makes things *worse* for the corner cases, since before the user would simply need a one-line edit to their xorg.conf, but now they have to restructure entire Sections before they can add their lines.

The old displayconfig-gtk tool had the problem that its backend was incompatible with xrandr, and because of this generated invalid xorg.conf's in many situations. It also had difficulty parsing and understanding the slimmed-down xorg.conf's; by design, the tool was intended to tweak existing xorg.conf's, not to build them up from scratch, and so it often would break as the monitor and input hotplug work progressed. That said, for the rare corner cases, it often *did* do a suitable job of configuring around the problem.

Similar to displayconfig-gtk, we also once carried a large, hard-to-maintain installation script, xserver-xorg.postinst, to walk the user through a set of text-only menus for hand-configuring monitors, setting up sync rates and resolutions, etc. Like displayconfig-gtk, this would often produce invalid configurations, and with the new hotplug capabilities became more of a problem than a help. However, also like displayconfig-gtk there were some corner cases where it was a necessary tool for recovering from broken X setups.

So, what we really need is a display configuration tool with the power to edit xorg.conf's easily for the user, like the old tools, but that works seamlessly with the new xrandr protocols, providing the user with the best of both worlds. Further, since in theory most hardware setups should be auto-configurable, this new tool should focus more on error recovery as a principle use case. Thus it needs integration at various points where a user with a broken X might find themselves - such as bulletproof-x, xfix, or even at a safe mode console prompt.

Use Cases

  • The xserver on John's computer fails because of an incorrect installation of a proprietary graphics driver. He needs to switch back to an open source driver from Bulletproof X.
  • Claire owns a graphics card whose driver doesn't support RandR and can't set the resolution which is more suitable for her monitor.
  • Mark wants to set up a multiple screens layout and add custom modes for each display.
  • Gwen wants to change the default settings of her TV (BOTTOM, RIGHT, TOP, LEFT, TV_FORMAT) permanently.

Assumptions

  • By default, everything should autoconfigure. This tool is assumed to be needed only when things are *not* working properly.
  • It is assumed that there will continue to be situations where things are not working properly.

Design

  • Simplified interface (for Bulletproof X):

    • works for drivers which don't support RandR
    • allows to change the graphics driver
    • saves the settings to the xorg.conf through X-Kit and PolicyKit (X will have to be restarted)

    • allows setting modelines created through either a port of Guidance code or GTF.
    • does NOT allow setting multiple screens layouts.
    • UI design to be derived/inspired from the displayconfig-gtk layout (but should be greatly simplified)
  • Advanced interface:

    • works for drivers which support RandR
    • allows setting resolution, refresh rate, and rotations/reflections
    • allows setting multiple screens layouts (only RandR 1.2 or higher)
    • allows setting output properties (only RandR 1.2 or higher)
    • allows setting gamma (only RandR 1.2 or higher)
    • settings are not saved in the xorg.conf (see the “Unresolved issues” section)
    • UI design to be derived/inspired from the Screen Resolution layout (with provisions for extending functionality)
  • Console interface:

    • works in situations where X cannot start and graphical tools can't be used for configuration
    • allows to change the graphics driver
    • runs as root/sudo user
    • saves the settings to the xorg.conf through X-Kit
    • allows setting modelines created through either a port of Guidance code or GTF.
    • does NOT allow setting multiple screens layouts.
    • UI design to be derived/inspired from the old xserver-xorg.postinst tool
  • Python RandR API:

    • relies upon either XCB or XLib modules
    • acts as an abstraction layer on top of which (very small) GTK (GDK) and QT4 (QX11Info) backends can be used.
    • Code duplication is minimal and it would be trivial to add backends for other widget toolkits (no more than 20-30 lines of code).
  • UI:

    • The first supported frontend will rely upon GTK.
    • A drawing area (using Cairo and GooCanvas for the GTK UI) will allow users to select and move displays, etc.

Implementation

  • XCB module is 85% complete:

    • Problems when setting 90/270 degrees rotations (xpyb bug).
    • Lacks the support for adding/removing custom modes.
    • Lacks the support for setting gamma.
  • Xlib module is (in theory) 70% complete:

    • Lacks access to EDID/properties. Lacks the support for proto (i.e. GetAtomName and InternAtom functions)

    • Lacks the support to add custom modes.
  • Simple GTK UI is available but has to be reworked.

Test/Demo Plan

Unresolved issues

  • How to save RandR settings?

    • Gnome Settings Daemon
      • Gnome-specific and there's nothing like this on KDE
      • It would require implementing the support for output properties in C (libgnome-desktop) and to adapt g-s-d's XML parser (and getting the whole thing accepted by upstream)
      • Beneficial from standpoint of gaining from GNOME upstream enhancements; on the other hand, coordinating/integrating Ubuntu customizations can be challenging
    • Custom Python script launched on login (not a daemon)
      • DE agnostic
      • can reuse the RandR API
      • easy to enable/disable
      • Drawback is that running python during login may slow down login
    • rc files parsed or sourced during login
      • build rc file support directly into xrandr and similar existing tools
      • DE agnostic since relies on X.org components
      • rc files tend to be simpler to troubleshoot than scripts or C code
      • Assuming the rc file support is passed upstream, will benefit from upstream's enhancements; possibly will gain support for new X features automatically (e.g., display properties are already provided in the xrandr tool)
  • GTK UI looks ugly when maximised (in Bulletproof X mode).

    • Caused by the lack of a window manager. If this can't be worked around within the application, should we adopt a lightweight wm for bulletproof-x? xdm?
  • KDE tool needed or is extending Krandr U/I better?

BoF agenda and discussion

Gobby session - UDS

 * no current replacement for displayconfig-gtk, based on guidance, which is now unmaintained and deprecated
 * in cases of xrandr/EDID failure, we still need modelines
 * Alberto is working on python-xrandr library to encapsulate common functionality (so far: lots of code dup between KDE and GNOME)
 * Don't rely on xrandr or xinerama; past has shown that xinerama does not reliably work on old hardware either

 * Lots of bug reports about setting resolution
 * 

= Simplified Mode = 
  * Supports old or broken hardware
 Bryce: Perhaps it could support different tools that produce different modelines
 Q: Could it cause a problem where the simplified mode comes up on the wrong monitor?
 
= Advanced Mode =
 * rewrite of backend to be desktop agnostic
 * stores configuration in .config/somefile.xml, not gconf (to work for KDE, too)
 * optionally stores config in xorg.conf to apply system wide
 
Q: Should advanced mode and simplified mode be in different applications, as they have minimal overlap?
 * Some shared libraries and shared UI
 * most functional parts should be in the backend, so if the two parts share code, that should move there
 * keep the possibility to improve the existing GNOME xrandr capplet instead
 

= Command Line Mode? =
 * does not require graphical display
 * ncurses?
 * command line equivelant of simplfied mode?
 
= Python randr API =
 * 
 
= Demo =
 * How to display when there are limited numbers of possible displays
 * Some people think the tabs are confusing
 * In randr you know what kind of display it is, so you could make nicer graphics to show the type of display
  * this is unreliable, so another way to do it would be to show connector type
 * Display properties are display specific, so need a parent/child relationship to handle
 * ICC profiles? Are we able to get them from the display, or will we have to ship them?
 * Next generation needs a "revert" dialog. Upstream didn't accept this.
 * Recovery, as a theme, we need a "revert" system so that if a user breas their settings (in any setting applet) there is a consistent GUI for reverting the change, and also a consistent way for deveopers to implement the change
 
= Can we just reuse the existing configuration GUI? =
 * More widgets
 * Need to make the window fit on netbooks
 
= How to Save Settings? =

= Hot Plugging? =
 * You plug in a cable and something pops up
 * Also keyboard shortcuts are busted
 
= Jaunty =
 * Backend work is a valuabe contribution
 * Extend/modify current UI
  * fit into netbooks
  * ask for design team help
  * coordinate with upstream
 * Make sure hotkeys are working
 * Postpone hot plugging till the future 

Comments


CategorySpec

X/Blueprints/ScreenConfigurationUI (last edited 2008-12-19 15:28:02 by host65-93-dynamic)