Skip to content

Add wlr-output-management-unstable-v1

Simon Ser requested to merge github/fork/emersion/output-management into master

This commit adds a new output management protocol. It can be used to get the current output configuration and apply a new one. It's based on the GNOME D-Bus API 1 and the KDE protocol 2 3.

Goals:

  • High-level API, not a copy of KMS
  • Protect against races wrt. hotplugging
  • Extensible via backwards-compatible changes
  • Atomic (both when reading current config and when applying a new one)

Features:

  • Read all outputs including disabled ones
    • Identification (name, description), available modes, physical size
    • Current mode, enabled/disabled
    • Position, scale, transform
  • Write
    • Modeset, enable/disable
    • Position, scale, transform

Non-features (ie. features in GNOME or KDE excluded from this protocol):

  • No DPMS (left out for another protocol because it can operate on wl_output)
  • No gamma ramps (left out for another protocol, we already have one)
  • Cannot set the primary logical monitor and the presentation monitor (should be a separate protocol, could use wl_output)

Available outputs and their current configuration are advertised when the client binds to the manager as "heads" (a head is an enabled or disabled output).

Clients can create a configuration object, add some outputs to configure and apply the new state.

The GNOME protocol has a concept of "logical monitor": it's a region of the screen you can assign physical monitors to. You can modeset and enable/disable physical monitors while you can position, scale and transform logical monitors. This nicely splits physical properties and logical properties. I've tried to design a protocol with a similar concept 4, but it turned out being pretty complicated since you need to have at least two extra objects (one to read the current logical monitors, one to configure them). I've decided against this approach for now.

TODO:

  • Custom modes
  • Check all of this makes sense for non-KMS outputs?
    • Some outputs have fixed modes, a size, a fixed refresh rate (KMS)
    • Some outputs have fixed modes, a size, a variable refresh rate (KMS + VRR)
    • Some outputs have no modes, a size, no refresh rate (Wayland backend)
    • Some outputs have no modes, a size, a refresh rate (headless backend)
  • Make sure a compositor can offload everything to a helper client (ie. it doesn't apply an initial default modeset on hotplug)
  • Should some features be optional?
  • Should zero modes mean the output doesn't support modes? What to do if an EDID is malformed and returns zero modes?

Possible future features:

  • Modes aspect ratio and interlaced modes
  • Underscanning? (needs investigation)
  • is-builtin property for heads? (should this be in the compositor?)
  • Expose suggested panel orientation and tiling data?
  • Variable refresh rate? (needs investigation)

Let me know what you think!

Fixes https://github.com/swaywm/wlr-protocols/issues/15

Merge request reports