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
* Output cloning with different resolutions or underscan
* Should transform & scale be per slot or per output device?
* Check all of this makes sense for non-KMS outputs?
* 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?
* Better wording
* 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)
References:
[1]: https://gitlab.gnome.org/GNOME/mutter/blob/master/src/org.gnome.Mutter.DisplayConfig.xml#L292
[2]: https://github.com/KDE/kwayland/blob/master/src/client/protocols/outputdevice.xml
[3]: https://github.com/KDE/kwayland/blob/master/src/client/protocols/output-management.xml
[4]: https://paste.sr.ht/%7Eemersion/8727ea50437fff3927c81c40c0ecc9c9885817ef
