DisplayConfigGTK

Differences between revisions 14 and 15
Revision 14 as of 2007-05-10 13:15:34
Size: 8249
Editor: 195
Comment:
Revision 15 as of 2007-05-10 13:35:07
Size: 8248
Editor: 195
Comment: "chantal" == "his" ?!?
Deletions are marked like this. Additions are marked like this.
Line 11: Line 11:
 * Chantal plugs in a second screen on his laptop and wants to expand his desktop to the new screen.  * Chantal plugs a second screen into her laptop and wants to expand her desktop to the new screen.

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

  • Chantal plugs a second screen into her laptop and wants to expand her desktop to the new screen.
  • Robbie 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 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).
  • Kim wants to change the default resolution for all users.
  • Hirsl wants to change the wrongly detected driver and screen

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 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".
  • 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 seems to sit in front of the computer to configure the network. Perhaps we should take the same approach here too.

    => Only ship one tool and only use a system-wide configuration (otherwise no way to configure gdm's resolution in a sane way).

  • What to do with other display configuration tools e.g. the one from GNOME? Remove them and only provide one? Power users that often switch resolution could still use the randr applet. Check other distros e.g. FC and OpenSuse.gobby.ubuntu.com

    => Only ship our tool

  • How to deal with non-admin users? Use dbus to allow console users to modify only a subset e.g. of options? possible tasks: clone/extend desktop, switching locations (profiles), changing monitors. We could allow the console user to call methods of a root running daemon (that could be launched by dbus activation or the system-tools-backend)

    => Take the dbus approach using the at console rights to configure X. This can be redecided if we run into problems and replaced by a more fine grained approach

  • 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

    => show a dialog if there is a new screen detected. Has to be added to the backend

  • 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.

    => get in touch with mvo

  • 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.

    => Xrandr 1.2 is a very new feature and has not been tested widely. Although it would rely on a second configuration mechanism. The best approach seems to be to store the configuration in the xorg.conf and only use xrandr if available for the card to establish the configured setup instantly

  • Think about integrating displayconfig-gtk into the system-tools backend

    => Seems to be out-of-scope. Main target for gutsy is rolling out a configuration tool. We may revisit better integration in the future.

  • Currently there is no way to get a signal from the server when a new monitor has been plugged 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.

    => No way to react on newly attached screens instantly (or showing a notification). So the user has to start detection in displayconfig-gtk himself

  • Integrate displayconfig-gtk into the failsafe mode of the x-server

    => Has to be worked on in the development process. This may be a situation where integration with the restricted manager might be useful, in that the user may wish to install a binary driver to handle graphics.

  • Add support for xorg.conf attachments in apport/provide a report bug button
  • The kde-guidance package has to produce a separate backend package and apply some minor patches

    => Would be worthwhile to create separate package for gtk-displayconfig from the kde one for tracking bugs, etc. Jonathan has to be contacted

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.

DisplayConfigGTK (last edited 2008-08-06 16:16:51 by localhost)