AllanDay, BastienNocera

Tentative Goals

  • Setup and configuration of (generally physically connected) displays
  • Rotate displays (either for laptops with rotatable displays or external monitors that rotate)
  • Configure properties of individual displays:
    • Brightness
    • Colour temperature
    • Resolution
    • Refresh rate (only for some displays - can be safely ignored for internal displays)
    • Overscan (only for TVs)
  • Set up multiple displays for different purposes:
    • Presentations - showing slides or content on another display, and use the internal display as a control
    • Join - join screen edges so things can pass from one display to another, as part of multi-monitor setups
      • Arrange the layout of displays when in this mode
      • Can sometimes include large numbers of displays (10+)
    • Mirror - show the same content on multiple displays; can be used for demos or for displaying content on another device (like a TV)
  • Select which displays to use:
    • Use a single external display when docked
    • Turn certain displays offin a multi-monitor workstation setup
  • Avoid showing someone's session to the world when they plug in a projector

Relevant Art



Project menu selects mode:






Some hardware might not be capable of outputting to a display at its natural resolution. in this case we "mirror" the displays, scaling up the output from the primary display to the secondary. The settings panel needs to communicate this state.

Tentative Guidelines


Previous design iteration


  • SeanMiddleditch: the displays should be very clearly numbered. Far more people in office situations have two identical displays than have a laptop and a monitor (at least in the service business and in the games business), and using the name is pretty worthless when you've got two or three monitors that are all 'Viewsonic 21.5" 1920x1080'. Hate to say it, but look at how Win7 handles this: each display is just a number, and the Identify feature slaps the number in full-screen glory onto each monitor. Makes it significantly easier to identify displays than names or colors.

  • It seems that the colouring of screens (which sort of fixed Sean's use case above) has been removed. what's the thinking behind that? (-- BastienNocera 2012-02-08 18:39:09)

  • The current (GNOME 3.4) implementation does not include any control for refresh rates. This can be troublesome in several use cases, especially with projectors: in particular, I witnessed this issue at EuroPython, where speakers were requested to use a specific resolution and refresh rate for frame grabbing purposes. In another case, I had to give a presentation with a flickering projector which was obviously able to cope with the resolution but not with the refresh rate. I think it is ok to hide refresh rates for LCD screens (is it meaningful at all?) but I would always show them for CRT/projectors. If it's not possible to reliably detect the kind of display, be on the safe side and show it always for the external (secondary) panel. (-- GianlucaSforna 2012-08-13 21:40:09)

Implementation notes

If we implement this, we should keep wayland in mind, as that changes radically the way multi-monitor is handled, giving the compositor access to the low level details.

In particular, see Wayland/Gaps/DisplayConfig for the proposed protocol to aid in this transition.

Under that proposal, the five options from the mockups would be implemented as follows:

  • Primary: assign the output its own CRTC, and mark the "primary" property
  • Presentation: assign the output its own CRTC, and mark the "presentation" property
    • Mutter will then take care of only showing "presentation" windows on that screen.
  • Mirror: assign the same CRTC as the primary output, if possible, otherwise assign its own CRTC and set the same geometry (and check that all outputs marked for mirror have suitable modes)
  • Combine: assign its own CRTC, with the geometry from "Arrange combined display" window, and clear the properties
  • Turn off: assign no CRTC.

Note: CRTCs (virtual heads) are a very scarce resource, most cards have 2 or 3. You may reach 4 if you count offloaded buffers between different graphic cards. On the other hand, it is technically possible to have more outputs, especially if you mix in docking stations and VGA multiplexers. We should detect those cases and either force mirror mode or turn off one of the two displays (as mirror mode might bring the resolution down to 1024x768 or 800x600)

Also applications need to be notified that a screen is presentation, and the compositor needs to know that a surface is really a presentation. It's easy to do it under X (a property on the root window with the Xinerama indices of presentation screens, and a property on the client window), but for wayland we need to invent a new protocol, extending wl_output and wl_shell_surface. Therefore, if presentation mode is really wanted, it's best to contact the wayland upstream developers and have the feature integrated there.

Still unclear:

  • What would be the application API for this? A property on GdkWindow?

  • Should apps be able to decide for themselves on which output they want their presentation, or should it handled by the toolkit/compositor?
  • Should Gdk report presentation screens as regular screens, for example in gdk_screen_get_n_monitors() and gdk_screen_get_monitor_geometry()?
  • What if legacy (not presentation screen aware) applications request to be shown on the presentation screen? Should the compositor move them away gently or just disable rendering them completely? What if the legacy app is fullscreen?

Design/SystemSettings/Displays (last edited 2017-01-26 13:49:31 by AllanDay)