DisplayConfigGTK

Differences between revisions 19 and 20
Revision 19 as of 2007-05-11 09:50:10
Size: 10306
Editor: 195
Comment:
Revision 20 as of 2007-05-11 09:51:01
Size: 10301
Editor: 195
Comment:
Deletions are marked like this. Additions are marked like this.
Line 45: Line 45:
 7. Add a screens changed mechanism to the backend and include a dialog for
   
these cases in the frontend
 7. Add a screens changed mechanism to the backend and include a dialog for these cases in the frontend

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 in a second screen on her laptop and wants to expand his desktop 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 prensentation 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

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.

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

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

Implementation

  1. Get displayconfig-gtk and a separated guidance-backend into main
  2. Use D-Bus to split displayconfig-gtk into a backend and frontend
  3. Raise awareness of the tool by news, blog and mailing list postings to get bug reports early
  4. Include support for different locations/profiles
  5. Evaluate if python bindings or ctypes could be used best for XRandR
  6. Include xrandr 1.2 support in the backend for instant applying of changes
  7. Add a screens changed mechanism to the backend and include a dialog for these cases in the frontend
  8. Remove GNOMEs resolution changing tool from the menu
  9. 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.
  • User wide configurations
  • Notifications when new screens are plugged in
  • Integration into the system-tools-backend (no python support)
  • No fancy preview widget
  • Profiles by using different ServerLayouts in a single xorg.conf

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". (In contrast to the KDE tool)
  • 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.

Screenshots (working)

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

Outstanding Issues

The failsafe mode is required to provide a fallback in the case of a misconfigurated X. The currently used testing mechanism by spawning a second X seems not work with all cards.

XRandR 1.2 is not tested widely and support situation is unclear. Furthermore there are no bindings.

GNOME screen resolution does not restore XRandR 1.0 rotation changes. The orientation can only be changed by XRandR, so we have to hook into the GNOME infrastructure here.

BoF agenda and discussion

User comments

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

UDS Sevilla

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

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