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 uses the same computer as A, but use a different screen resolution than A.
• 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.

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.

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.

* Rodriguez came up with the idea to use profiles like the networking tool. this could be done using different server layout sections and pointing to the current one by 'Option "DefaultServerLayout" "layout-id"' in the serverflags section. this would avoid storing the data in a second place. this also seems to be ok from a x-devel point of view

* The configuration will still be based on the xorg.conf. xrandr, if available, will be only used to instantly apply the changes

* 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)

* displayconfig will be used in the failed x session to allow the user to reconfigure the system

* we will not make any difference between a user and system wide settings.

* it would be nice to have the user in front of the computer always have full control of the configuration like network-manager. open security issues? setuid? sudo? dbus (dbus activation to avoid having an always running daemon)?

* integration with restricted-manager?