Ubuntu Wiki

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.

Use Cases

• User A plugs in a second screen on his laptop and wants to expand his desktop to the new screen.
• User B tends to work at home with his laptop too. He would like to easily switch between his configuration setups: at home using an old crt monitor to extend his laptop, on the road to give a prensentation on a projector and at work with his shiny new mac cinema display. (The base station in his work could even include a different pci express card).
• User C wants to change the default resolution for all users.

Implementation Plan

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 there is currently no widely deployed xrandr1.2 support, the configuration would still be based on the xorg.conf, but make use of the xrandr to apply configuration changes instantly. This will use different mechanisms, but should result in the same end.

Implementation

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

Ideas

• 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 attemp 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".
• Using icons for the screens that help to identify them (normal screen, widescreen, laptop panel or tv out).

Screenshots (working)

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

Outstanding Issues

• How to make a clear difference between system and user settings? Should there be a difference at all? Network manager allows all user who seem to sit in front of the computer to configure the network. Perhaps we should take the same approach here too.
• What to do with other display configuration tools e.g. the one from GNOME? Vanish them and only provide one? Power users that often switch resolution could still use the randr applet. Check other distros e.g. FC and SuSE.
• How to deal with non admin users? Using dbus to allow at console users to modify only a subset e.g. of options? possible tasks: clone/extend desktop, switching locations (profiles), changing monitors. we could allow to the at console user to call methods of a root running daemon (that could be launched by dbus activation or the system-tools-backend)
• How to make a change of the screen devices visible in the user interface? Switch to an unamed location/profile? Still show a grayed out monitor that was configured in the xorg.conf next to the new one that was detected by xrandr? Show the screen detected by xrandr and not the configured one? How should the user apply the changes if we only
• How to allow different profiles/locations e.g. at "home" with an extend desktop, on the "road" with an projector, at "work" using a different screen device? Could be stored inside of the xorg.conf using different serverlayouts and switching them using the defaultserverlayout option in the serverflags section or use completely different configuration files. (highly requested by customers)
• No python bindings for xrandr 1.2. Possily ctypes would be enough.
• Xrandr is currently supported by the Free Radeon, Nouveau and Intel driver. NVidia plans to add it in the future (but likely only for newer cards). No information from AMD/ATI.
• Think about integrating displayconfig-gtk into the system-tools backend
• Currently there is no way to get a signal from the server when a new monitor has been pluged in (dbus support seems to be on the way, but this feature is also not supported by all cards and drivers). Furthermore not all cards are capable of this.
• Integrate displayconfig-gtk into the failsafe mode of the x-server
• The kde-guidance package has to produce a separate backend package and apply some minor patches

BoF agenda and discussion

• WolfgangSilbermayr:Wouldn't it make more sense to implement Multi-Screen instead of Dual-Screen? I think there are more and more systems available with two PCI-Express slots and sooner or later people will want to use three or four screens. Reply SebastianHeinlein: Currently the backend only supports two screens. Allowing to freely define more than two screens adds a lot of complexity.

• TrondAndersen: I think it's important to have support for dynamic display devices. When I remove my laptop from my docking, Ubuntu should figure out this and disable the second display so that new application windows doesn't appear on a non-existing area. When I plug in the cable to a projector, Ubuntu should find the new display device and my preferences about projectors should be followed. Ubuntu should find out what resolution this device supports and remember my overrides if I choose to do so. Is XRand the way to go? These use cases should be added. Reply SebastianHeinlein: The xrandr infrstructure will allow this in the future. But there are only some beta Intel drivers available yet. I don't know if it will ever be supported by ATI or NVidia.