The Multi-Monitor User Experience

Registered by Chris Halse Rogers

The kernel / X multi-monitor stack is now pretty complete from a technical perspective.
The user-experience now needs to be fleshed out so that we have sensible defaults when users plug in an extra monitor.

What should be the default behaviour when:
 * A user plugs in a projector?
  + How do we distinguish a projector?
 * A desktop user plugs in an extra monitor
 * A laptop user plugs in an extra display when…
  + It's in a docking station
    - Should we change the lid-switch behaviour in this case?
  + It's stand-alone

Blueprint information

Status:
Started
Approver:
Sebastien Bacher
Priority:
Medium
Drafter:
Chris Halse Rogers
Direction:
Needs approval
Assignee:
Chris Halse Rogers
Definition:
Approved
Series goal:
Accepted for quantal
Implementation:
Started
Milestone target:
milestone icon ubuntu-12.10-beta-1
Started by
Kate Stewart

Related branches

Sprints

Whiteboard

raof 2010-11-05: Moved user stories to the wiki page

raof, 2011-11-16: The design team have multi-monitor plans and UI; dropping my related WI. The library component is rolled into libxrandr-utils. Postponing keeping the kms-set mode on startup; it's a nice-to-have, not a requirement.

pitti, 2010-11-08: Thanks so much on working on this. The user stories and design decisions fullfil the "least surprise" and KISS principles, and will improve the user experience a lot indeed.

broder, 2011-01-05: It looks like there has been some work done on a small UI that shows up when you hit the display hotkey at https://bugzilla.gnome.org/show_bug.cgi?id=600774, but it hasn't gotten any love in almost a year.

broder, 2011-01-12: I experimented some more with how OS X handles laying out new monitors. It looks like it clones by default when you connect a projector, but extends by default when you connect a monitor. I'm assuming that it's guessing based on the physical dimensions from the EDID (i.e. projectors have width=height=0mm). Should we expand our desired behavior to do the same thing?

raof, 2011-01-12: Our reasoning behind cloning by default is to ensure that the display configuration popup is definitely visible on at least one monitor the user can see. Otherwise plugging in a monitor which is not turned on (or other such edge cases - docking is a good source of these) could result in the monitor configuration popup being not visible to the user, and any applications which launch to that monitor would appear to silently fail to launch.

The other solution would be to have the display configuration popup on all connected displays; this would eliminate my concerns, but I'm not sure if others have further concerns.

We won't be shipping the new gnome-control-centre in Natty due to dependencies, so this work won't land completely for Natty, but should be ready and waiting for Natty+1 when we switch to the new GNOME 3 control centre.

pitti, 2011-02-21: Not started, and three days before FF -- moving to 11.10

raof, 2011-05-18: This was discussed again at UDS-O in https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-dual-monitor-support. There the consensus was to clone projectors by default, but span (our current behaviour) monitors by default, and pop up the UI on all connected displays. Updated WI.

pitti, 2011-07-19: Moving to p series, as there hasn't been much activity on this. If you still want to pursue this for oneiric, please yell.

(?)

Work Items

Work items:
[repete] Collect existing use-cases for multiple monitor support: POSTPONED
[raof] Investigate how to distinguish projectors / TVs / monitors: DONE
[raof] Add support to X for keeping the KMS-set mode on startup: POSTPONED