Ubuntu Wiki

• Launchpad Entry: desktop-p-multi-monitor

• Created:

• Contributors: bryce raof

• Packages affected: Xserver, gnome-settings-daemon, gnome-control-center

Summary

Improving the MultiMonitor experience in Precise needs a) Solving several notable design issues in Unity, b) fixing problems with the configuration tools, and c) fixes and standardization at the plumbing layer.

This blueprint serves as a high-level collecting point for other bugs, blueprints, and branches that aim to address these problems, so all design and implementation work should be split out separately for tracking purposes.

Release Note

The handling of multiple monitors has been improved, making it easier to enable and configure a second display. Particularly, it is easier to set up a projector for a presentation.

Rationale

Multi-monitor support requires precision at three layers:

• The window manager layer (unity, metacity, etc.)
• The configuration layer (e.g., gnome-control-center)
• The plumbing layer (X and the kernel)

Unity has brought new design ideas to the desktop, however multi-monitor functionality has been flagged as an area needing further attention during Precise development.

These regressions are unfortunate, but multi-monitor support has never been perfect in Desktop Linux. There are many ways to arrange multiple monitors, and many use cases that don't receive proper testing or for which the proper behavior is not obvious. In particular, we discussed these problems in Natty UDS in the multimedia-desktop-n-xorg-multihead-defaults blueprint. While that focused on problems people were experiencing in metacity and compiz, most of those issues are general problems and still applicable for Unity. The good news is that Unity gives us a chance to re-think monitor policy and aim to solve a broader range of use cases; while our top focus in Precise is to solve the glaring regressions, the design effort will try to establish a framework to enable us to address the wider set of problems that users have been struggling with for years.

The configuration layer in particular has been problematic since the start, partly because a lot of low level fiddly X technical work is being done in config tool logic that probably would be better done in X11 since it can be hard to do right, and would benefit from having direct oversight by X.org experts. Solving this could give a much firmer foundation to multi-monitor functionality; one solution to this is discussed in the desktop-p-libxrandr-utils blueprint.

As of 2011, the plumbing layer is stable (modulo bugs), with the exception of the -nvidia driver. Nvidia is the one driver remaining that still lacks support for RANDR 1.2; it is able to achieve much the same effects using TwinView and Xinerama, but these technologies work differently enough that it multiplies the number of places where things can go wrong, thus multiplying the amount of testing, documentation, and bug work required.

User stories

Alan goes to the office, puts his laptop with the lid closed into a docking station and boots it up. The external display should be run at its native resolution. Later that day he needs to see a customer. He suspends the laptop and takes it out of the docking station. At the customer he wakes up the laptop and the internal screen is used at its native resolution. Finishing his visit the laptop is suspended, brought back to the office. There it is placed in the docking station, woken up and the external display should run again at its native resolution.

Bob starts his day in a presentation, booting the laptop with lid open while attached to a projector. He delivers the presentation in clone mode. He suspends the laptop, closes the lid and walks to his office. The laptop is placed in a docking station and woken up. The external display should be used in its native resolution. When going home he suspends the laptop and takes it with him. At home the laptop lid is opened, the system resumes and the internal display is used at the native resolution.

Charlie uses the train in the morning and uses his laptop there. When leaving the train he suspends the system. At work he gives a presentation first, resuming the laptop with the projector attached. He gives the presentation in clone mode. After the presentation he suspends the laptop, walks to his office and places it in the docking station there. With the lid closed he resumes and works with the external display with native resolution.

David works from home in the morning, using his laptop in native resolution. Later that day he visits his office, places the laptop with lid closed in the docking station and works on the external display in native resolution.

Design

From the old multimedia-desktop-n-xorg-multihead-defaults blueprint.

Default on monitor plug-in event: suggested clone mode when connecting a second monitor - OS X and W7 appear to default to clone

Default to resolution of smaller device (within sane ranges), letterbox on larger device.

On display plug-in event, pop up new GUI with a few, graphical, sane defaults presented to user.

Hot-key should bring up same display chooser as display hotplug - preferably it can be configured on the dialog what the hot key does. User can select to have the hotkey switch between a chosen set of configurations.

A popup UI for the Monitors applet needs to be developed.

The Monitors applet from GNOME Control Center is responsible for the multi monitor UI; this needs to be extended to add the simple UI popup.

The xrandr plugin to GNOME settings daemon is responsible for handling hotplug events and setting modes; this needs to be changed to default to clone in the absence of previous configuration.

Implementation

Implementation to be discussed on separate blueprints/bugs/branches as appropriate

Test/Demo Plan

Multi-head is notoriously difficult to test due to the need for having an array of hardware on hand that covers a breadth of physical designs, and that can be dynamically mixed and matched to simulate user plugging/unplugging and rearranging. There are no synthetic tests for this so traditionally it's been done on live hardware. Automated testing is complicated by the fact that specialty KVMs and other such devices are required to enable switching things programmatically. Due to all these factors, most multi-head testing will need to be done manually. That said, where there are specific chunks of code that can be synthetically tested, we should write unit tests to do so.

Some workloads have been written for xdiagnose to exercise setting up / tearing down multi-head configs while running various stresses (playing a movie, starting/stopping GLX programs, etc.) These tools should be extended to cover a broader range of effects and issues.

CategorySpec