Displays

Participants

AllanDay, BastienNocera

Tentative Goals

  • Add displays for different purposes:
    • Combine displays to be part of multi-monitor setups
    • Mirror your desktop on another display - can be used for demos or for ad hoc presentations - using non-standard presentation software
    • Identify and configure a display to be used by presentation software
    • Displaying video or photo slideshows (either through a physically connected display or networked displays)
  • Arrange displays when they are part of multi-monitor setups
  • Avoid showing someone's session to the world when they plug in a projector
  • Change resolution and refresh rate

Relevant Art

MeeGo

monitors.png

OSX

OSX_displays.png

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.

When setting up multi-monitor, it would make sense to treat the combined displays as a single one to be configured.

Tentative Guidelines

https://raw.github.com/gnome-design-team/gnome-mockups/master/system-settings/displays/displays-v2.png

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?

Design/SystemSettings/Displays (last edited 2013-07-19 15:39:43 by GiovanniCampagna)