DisplayConfigGTK

Differences between revisions 29 and 30
Revision 29 as of 2007-05-31 18:15:33
Size: 11132
Editor: p57AEDA11
Comment:
Revision 30 as of 2007-05-31 21:16:59
Size: 8537
Editor: 71
Comment: Integrating user comments and UDS discussion
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:

See also:
 * ["Xorg7.3Integration"] - Adoption of Xorg 7.3 components including xrandr 1.2
 * ["BulletProofX"] - Failsafe mode that uses displayconfig as primary configuration tool
Line 20: Line 24:
 * 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.  * 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.
Line 28: Line 32:
displayconfig-gtk will be accessed from the existing System > Preferences > Screen Resolution dialog, via an "Advanced..." button on that dialog.
Line 32: Line 38:
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. We still have to wait for the updated drivers to get test results, but XRandR 1.0 has got problems with Xinerama based layouts. 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.
Line 38: Line 44:
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).
Line 40: Line 48:
== Implementation == 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.
Line 42: Line 50:

=== Implementation ===

 0. 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)
Line 43: Line 57:
     * Add apport hook for attaching xorg.conf and output from `displayconfig-gtk -w pcitable.txt`
Line 45: Line 59:
 
Line 47: Line 60:
 
Line 49: Line 61:
 
Line 51: Line 62:
 
Line 53: Line 63:
 
Line 55: Line 64:
    
Line 57: Line 65:
 
Line 63: Line 70:
  * 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)
Line 64: Line 82:
 * User wide configurations
 
 * Notifications when new screens are plugged in
Line 68: Line 83:
 * Integration into the system-tools-backend (no python support)
  
 * No fancy preview widget
 
 * Profiles by using different ServerLayouts in a single xorg.conf

 * Pure XRandR 1.2 with hotplug support
 
Line 92: Line 99:
Line 93: Line 101:
Line 95: Line 102:
Line 98: Line 104:
==== Ideas ==== ==== Requirements ====
Line 103: Line 109:

 * User should be able to select/install binary graphics drivers. Possibly this could be done by integrating/depending on the restricted driver manager.
Line 116: Line 124:
== BoF agenda and discussion == == Test Plan ==
Line 118: Line 126:
=== 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.
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
Line 122: Line 131:
 * ''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.
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 ?
 * Test with Xinerama, Twinview, Compiz configurations
Line 125: Line 138:
 * Fedora 7 has a nice GTK tool for setting up Screen Resolution & Dual Head mode - maybe we could reuse some of their code or ideas? --AzraelNightwalker

 * AFAIK the code is based on kuduzu and also has got its problems. [SebastianHeinlein]

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

 => 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
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

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

Screenshots (working)

attachment:displayconfig1.jpg attachment:displayconfig2.jpg attachment:displayconfig3.jpg attachment:displayconfig4.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 ?
  • 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

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