Displays

Participants

AllanDay, BastienNocera

Goals

Functional requirements:

• Individual display settings:
  • Rotation (for laptops with rotatable displays or external monitors that rotate)
  • Resolution
  • Display scaling, including fractional scaling
  • Refresh rate (only for some displays - can be safely ignored for internal displays)
  • Overscan (only for TVs)
• Multiple display configuration
  • Join displays
    • Set where the edges should be joined
    • Select a primary display
  • Mirroring
  • Use a single display - sometimes needed when a laptop is docked and the user wants to disable the internal screen while leaving the lid open
  • Turn off individual displays:
    • Could be a TV or presentation display that isn't in use
    • Could be rare cases where graphics hardware isn't powerful enough to drive all the connected displays
    • One display should always remain active
• Global settings:
  • Brightness
  • Automatically dim screen
  • Automatic brightness (using photometer)
  • Night light

Experiential goals:

• Common cases should be obvious and easy
• Take the pain out of presentations
  • Protect the user's privacy: don't show their session when they plug in a projector

Non-goals:

• Large-scale media installations

Use Cases

Displays are used:

• As the "workspace" - how the user interacts with the device
• For presentations
• For demos

Presentations can use a dedicated app. Sometimes they involve multiple apps and demo segments (which requires being able to show any window on the presentation display).

Presentations can be slides, photos, video. Presentations typically happen on a single display, but there are cases where there might be more than one.

Some presentation software has a presenter display which is different from what is shown to the audience. You can have a single presenter display and multiple presentation displays.

Number of displays

A single built-in display is most common. Next most-common case is two displays, as either:

1. Laptop and docked external monitor
2. Two external monitors with a desktop machine
3. Laptop and presentation screen (either big LCD or projector)

Three displays or more are less common but do happen. these can be presentation setups but are more likely to be multi-display workspaces. It is difficult to put an upper limit on the number of displays we need to support.

Relevant Art

Windows

Project menu selects mode:

OSX

Chrome OS

Discussion

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.

One of the main challenges with the display settings is how to support the common cases well, while also supporting all the poorly defined edge-cases, and not have a complexity explosion in the process.

Presentations

In the past we've discussed having a presentation mode. This would:

• Not join the presentation display to the presenter display
• Use a generic rather than a personalised wallpaper
• Advertise presentation displays to presentation software

This would avoid the user's pointer from accidentally ending up on the presentation display (which might well be behind the user). It would also avoid showing personalised wallpapers to the world.

Presentation mode will not really work for demos, since you cannot have the pointer on the display.

We probably also need to recognise that there can be multiple presentation displays.

Tentative Guidelines

Relevant Bugzilla Links

• https://bugzilla.gnome.org/show_bug.cgi?id=655041 (missing refresh rate setting)

• https://bugzilla.gnome.org/show_bug.cgi?id=600225 (usability of "Apply". Issue from 2009, possibly not relevant anymore)

• https://bugzilla.gnome.org/show_bug.cgi?id=585687 (usability, moving monitors around, looks an easy fix)

• https://bugzilla.gnome.org/show_bug.cgi?id=636216 (discoverability, setting the primary monitor)

• https://bugzilla.gnome.org/show_bug.cgi?id=590807 (mapping, identical monitors)

• https://bugzilla.gnome.org/show_bug.cgi?id=689676 (colours to identify displays)

• https://bugzilla.gnome.org/show_bug.cgi?id=655041 (need to configure refresh rate)

• https://bugzilla.gnome.org/show_bug.cgi?id=677399 (confusing when there's only one display)

• https://bugzilla.gnome.org/show_bug.cgi?id=590807 (disambiguate monitors of the same model)

Comments

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