Ubuntu Wiki

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: displayconfig-gtk

• Packages affected: kde-guidance (new GTK frontend), xrandr, gnome-control-center

See also:

• ["Xorg7.3Integration"] - Adoption of Xorg 7.3 components including xrandr 1.2
• ["BulletProofX"] - Failsafe mode that uses displayconfig as primary configuration tool

Summary

This specification describes the user interface, packaging and code aspect of a GTK port of the displayconfig tool of guidance, the KDE system administration suite.

Rationale

Most hardware of the system is configured automatically. But this is not the case for screens and graphic cards. E.g. currently there is no graphical way in a GTK/GNOME environment to extend the desktop to a second screen. Furthermore this tool is required for a failsafe mode of the X server to correct misconfigurations.

Use Cases

• Maral plugs a second screen into her laptop and wants her desktop to expand to the new screen.
• Sepp tends to work at home with his laptop too. He would like to easily switch between his configuration setups: at home he's using an old CRT monitor to extend his laptop screen space, on the road he gives presentation on a projector and at work with he works in front of his shiny new mac cinema display.
• Vroni wants to change the default resolution for all users.
• Hirsl wants to change the wrongly detected driver and screen.

Implementation Plan

displayconfig-gtk will be accessed from the existing System > Preferences > Screen Resolution dialog, via an "Advanced..." button on that dialog.

Since guidance already provides a backend for the X server configuration written in Python, the main task will be to write a frontend with pygtk.

There should be some interaction/cooperation with xrandr developers. Pascal Schoenhardt works on a [http://code.google.com/soc/gnome/appinfo.html?csaid=F9CE6F874146B221 Google SoC project] to get xrandr 1.2 support to GNOME.

Since xrandr1.2 support is still fairly new, the configuration would still be based on an existing xorg.conf, but make use of the xrandr to apply configuration changes instantly. This will use different mechanisms, but should result in the same result.

If the changes require to restart the X server we send a safe restart signal to the gdm daemon. The backend detects if we neeed to restart x, the computer or can apply the changes instantly.

Locations/profiles will be implemented by using a different xorg.conf for each one.

If there is a change in screen devices, such as if the user has swapped monitors, the old display should be grayed out and the new xrandr-detected one highlighted. A dialog should be presented to the user informing them of the change in monitors, and allowing them to either keep or discard the old monitor (in case the monitor change is only temporary).

To ensure integration with existing gconf based XRandR configuration, we have to reset them if the user changed the resolution in displayconfig-gtk. (The frontend runs as the user, since we use dbus).

Since displayconfig-gtk will also be used as a primary configuration tool in failsafe modes, it will also be necessary to start up displayconfig-gtk with some additional widgets, such as a welcome screen and a 'skip' button. See the ["BulletProofX"] spec for complete details.

Implementation

1. Pre-requisites
   • python bindings for xrandr 1.2. Possibly ctypes would be enough. (See mvo)
   • separate backend package from kde-guidance, with some minor patches included. (See Jonathan)
2. Get displayconfig-gtk and a separated guidance-backend into main

   • Add apport hook for attaching xorg.conf and output from displayconfig-gtk -w pcitable.txt

3. Use D-Bus to split displayconfig-gtk into a backend and frontend
4. Raise awareness of the tool by news, blog and mailing list postings to get bug reports early
5. Include support for different locations/profiles
6. Evaluate if python bindings or ctypes could be used best for XRandR
7. Include xrandr 1.2 support in the backend for instant applying of changes
8. Add a screens changed mechanism to the backend and include a dialog for these cases in the frontend
9. Evaluate the removal of GNOME's resolution changing tool (gnome-display-properties) from the menu
10. Ensure correct documentation and recommendation of the GNOME RandR applet for power users in the desktop guide

Out of Scope

• The tool will not allow to configure more than a dual screen setup.
  • Multi-screen involves a much higher amount of complexity. It is felt that the user base for 3+ display situations is going to be very small, and probably will be technically capable of handling manual configuration.
• User wide configurations
• Notifications when new screens are plugged in
  • While this is definitely an important capability, we need to wait for more complete support for this in xrandr-supporting drivers. It's questionable if ATI or NVidia will ever support this. For now, this will rely on the user starting detection in displayconfig-gtk.
• Integration into the system-tools-backend
  • s-t-b does not have python support, so integration may be complex
  • This should be re-examined for gutsy+1; for gutsy we just want to get the configuration tool in place
• No fancy preview widget

• Profiles by using different ServerLayouts in a single xorg.conf

• Pure XRandR 1.2 with hotplug support
• Input hotplug (xserver 1.4 feature)

User Interface

Style

To be consistent with the other system administration tools of GNOME a capplet approach using explicit apply is chosen.

Object of the capplet

The main object of the capplet are screens. But since we cannot always ensure to detect the screens and their name correctly we have to make it possible for the user to define screens by the corresponding graphics card and output.

Basic layout

The capplet is separated into three sections:

• display mode: allows to configure the display mode of all screens
• dual screen mode: currently only dual screen is supported by the backend
• devices: allow to define device drivers

Requirements

• The screen has to fit on a 640x480 screen, since this is the fallback resolution of misconfigured devices.
• If the user clicks on the device button he or she wants to change the device. So doing an autodetection attempt and trying to select the detected device seems to be more helpful than to select the current one. Furthermore this avoids an extra click and button "select detected device". (In contrast to the KDE tool)
• User should be able to select/install binary graphics drivers. Possibly this could be done by integrating/depending on the restricted driver manager.
• Using icons for the screens that help to identify them (normal screen, widescreen, laptop panel or tv out). The first device should always be provided by the internal laptop output.
• Improvements in the user interface are discussed on the ubuntu-desktop list

  • https://lists.ubuntu.com/archives/ubuntu-desktop/2007-May/thread.html The new design would allow to add custom options to the graphics card device section and the steps that are required to change a screen are less.

Screenshots

UDS Sevilla

attachment:displayconfig1.jpg attachment:displayconfig2.jpg attachment:displayconfig3.jpg attachment:displayconfig4.jpg

Current

attachment:current-screens.jpg attachment:current-gfx.jpg

Test Plan

Unit Testing

• Starts up when no xorg.conf is present
• Starts up when an invalid/incomplete/broken xorg.conf is present
• Compare generated xorg.conf output to expected xorg.conf

Acceptance Testing

• Verify all commandline options work
• Verify works on 640x480 screen resolution
• Verify that restricted drivers (nvidia, fglrx) can be installed on a fresh system

  • - May require some level of integration with the restricted driver manager ? (It would surely be easier to simply check if the restricted driver packages are installed -RobertoSarrionandia)

• Test with Xinerama, Twinview, Compiz configurations

Usability Testing

• Check that a novice user is able to easily locate the tool for each use case scenario
• Check that a non-admin user is able to adjust their resolution higher or lower or rotate the display without needing admin-level access

Comments

• NicholasTelford: Looking at this spec and the mock-ups above it seems to imply that this will only work for single and dual head configurations. What about people with more than 2 screens? What about people (especially laptop users) who frequently switch screen configurations? I propose two things:

  • Allow configuration of an arbitrary number of screens instead of having a "Dual Head" tab. Windows has done this for years, I'm fairly sure Mac OS X does this too.
  • Have the notion of "profiles" that can be saved. If it's possible, have a profile automatically load when it's associated screens are detected. i.e. if the user has saved a profile for their home screens and a profile for their work screens it'll automatically switch based on the screens that have been plugged in.

• SebastianHeinlein: I don't think that there are so many users having three monitors. The primary target is getting a working solution for Gutsy. Adding support for more than two monitors would require deeper changes in the backend. Locations/profiles are already implemented, but only with a chooser and there is no automatic detection. The automatic detection would make more sense on a only XRandR based configuration tool. Currently you have to log off and relogin to apply your changes (for the dual head configuration)

• Ttoine: I think that it is important to let the user have the choice. I agree with the fact almost users use only one or two screens. But for someone using Ubuntu for Video Jay application, or wanting in some professional/industrial use of Ubuntu to set up 4 screens with, for exemple, using a nVidia SLI... why would one need to go to command line and text file edit to tweak what he/she need to work?? Having a simple GUI is important for most users, and it is missing. But it is important too that user coming from other OS to Ubuntu don't feel too limited. And that' a point!

• NathanHandler: I think that the first priority should be getting this working with two monitors. Once that is accomplished, and released, it can be updated to support more than two monitors. Also, most of the people using more than two monitors are usually more experienced with computers, and could probably figure out how to set it up by themselves.

• Ttoine: Sebastian wrote that it would be a deeper change to support more than two monitors... why do the job twice : one time for 2 monitors, and doing all again for more ? It is just question, I don't want to convince anybody...

• SebastianHeinlein: Titoine, you don't have to convince anyone. If you want to support the development of this tool test it on your systems, report bugs and/or submit patches. We also have got a team that you can join if you want to work on the source code: https://launchpad.net/~displayconfig-gtk I have got my final exams next week and so the development is currently quite on hold. You can find Feisty packages on my site: http://glatzor.de/filesink/displayconfig/feisty/

• Peet42: I'm a dual-head user, and one use for more than two screens would be to enable the TV Out on my card so I could play Xine movies on my TV while I work...

• Fafek2: What about some basic adjusts like gamma or brightness? I suppose it's not possible in this version, but I think you should consider some troubleshooting options like disabling acceleration or AGP support also. Some options like configuring TV-Out (TV standard and format) would help users to set up TV correctly without hassle. Unfortunately, I do realize that most of these features (except gamma and brightness) are driver-dependent.
• BUGabundo: @Peet42, can you help me set up my intel card, to use detect and use my laptop svideo? I've looked all over and cant get it to work. Thanks
• Ttoine: Where can we test that ? (sources or .deb ?)

• You can test it by installing Gutsy and then installing the displayconfig-gtk package. Or you can get the code here: https://code.launchpad.net/~displayconfig-gtk/displayconfig-gtk/ubuntu - bryce 7/14/07

• gQuigs: I really don't like the three monitors equals technical assumption. Three monitors is a piece of cake to configure in Windows or in Ubuntu with nvidia-settings (and requires little technical knowledge).
• Vit Hrachovy: It would be very useful to add support for changing bit depth (8-bit, 16-bit, 24-bit, 32-bit) of display and save as a profile.

• SteveLoughran: Can I point people at some past work of mine in this area, [http://www.hpl.hp.co.uk/techreports/2000/HPL-2000-21.pdf the secret life of notebooks]. This first study showed that laptop users had a broad set of contexts -not locations, contexts- which kind of combined system settings (network, proxy, printer,display) with what they were doing. The followup, and [http://www.hpl.hp.com/techreports/2001/HPL-2001-158.pdf Towards an Adaptive and Context Aware Laptop], was a windows prototype of a tool that would guess the current context from user state (Powerpoint and acroread fullscreen = presentation, home WLAN=home, work LAN+power=desk, work WLAN or battery in office hours=meeting) and changed power policy, printer settings, proxy setup, etc. We could do this properly in Linux, integrating network context with power information and display, learning locations and doing dynamic things. I do think it is an ambitious goal, that of having superior roaming capabilities to either Windows or the mac, but it is possible. For now, different display settings (twin monitor, single monitor cloned, home monitor, monitor+TV out) should be given names and possibly integrated with power policies (so the tvout mode for DVD playback disables screeen blanking). Then we can work on a way of merging monitor context with network context, as time goes on.