GraphicalXConfiguration

Differences between revisions 21 and 22
⇤ ← Revision 21 as of 2006-11-01 02:28:48 →
Size: 2556
Editor: d64-180-214-139
Comment: more stuff
← Revision 22 as of 2006-11-01 02:37:21 → ⇥
Size: 2816
Editor: wsip-68-15-230-31
Comment: modified use case for multiple monitors instead of just dual head
Deletions are marked like this. Additions are marked like this.
Line 16: Line 16:
Brian wants to add a second monitor. He has either a second graphics card or a video card with two video outputs. He goes to System>Administration>Video Settings (or similar) and clicks to add a new screen. A wizard guides him through setting graphical options. Brian wants to add additional monitors to his system. He has either multiple graphics cards, a video card with two video outputs or a combination thereof. He goes to System>Administration>Video Settings (or similar) and clicks to add a new screen. The Video Settings dialog allows Brian to identify each screen and then use a GUI to tell the system about the physical relationship of each screen (i.e. screen A is to the left of screen B). A wizard guides him through setting graphical options (Xinerama, Twinview, etc).

Summary

We need an easy way for people to change their X configuration in a sane way, including enabling 3D acceleration, 2 monitors, etc.

Rationale

As it stands, configuring X involves the manual editing of a text-based configuration file, which is not particularly well-commented. The xorg.conf file is also probably going away entirely.

Use cases

Brian wants to add additional monitors to his system. He has either multiple graphics cards, a video card with two video outputs or a combination thereof. He goes to System>Administration>Video Settings (or similar) and clicks to add a new screen. The Video Settings dialog allows Brian to identify each screen and then use a GUI to tell the system about the physical relationship of each screen (i.e. screen A is to the left of screen B). A wizard guides him through setting graphical options (Xinerama, Twinview, etc).

Scope

Packaging an existing GUI tool. Nothing more, nothing less.

Design

<to-do>

Implementation

A number of tools already exist. We need to look at all of them for sanity and ease of packaging.

system-config-xfree86

  • Created by Red Hat. Written in Python and pyGTK, which is a good sane language. UI is clear and easy to understand and is focused on what the user wants to do, rather than the syntax of the existing xorg.conf

http://fedora.redhat.com/projects/config-tools/redhat-config-xfree86.html

Xorg-Edit

  • Created specifically for Ubuntu. Exposes much of the syntax of xorg.conf and uses wxWidgets, which are not in main. Unsuitable

http://www.cyskat.de/dee/progxorg.htm

Sax2

  • Complete tool to control X, not just a GUI. Unknown how it will deal with new Xorg input and output hotplug. Allows configuration of tablets, etc. Large amounts of code to be audited.

http://sax.berlios.de/

Guidance

  • Written to be "the KDE system tools". Written in Python. Already shipped with Ubuntu for Kubuntu. Modular to allow GTK frontend to be written.

http://www.simonzone.com/software/guidance

Code

Available from above link. Work needs doing. See below.

Outstanding issues

There is new code landing in Xorg for the handling of input and outplug devices automatically. This new code means much of Sax2 and potentially Guidance might be obsolete.

The gui should not be able to leave the user in an unbootable state. There is another spec for dealing with X failures: https://features.launchpad.net/distros/ubuntu/+spec/bullet-proof-x

CategorySpec

GraphicalXConfiguration (last edited 2008-08-06 16:39:19 by localhost)