Currently only background and bottom layers can have surfaces with
normal focus semantics. Allow top and overlay layers to have these
semantics too (instead of exclusive).
Closes: https://github.com/swaywm/wlr-protocols/issues/32
Make it clearer what the two possible modes are, and expose enum values
instead of requiring clients to use 0 or 1.
Also clarify that compositors aren't required to give focus if keyboard
interactivity is exclusive.
Some window switchers, like mobile ones, may want to skip or group
dialogs and other child windows on their window lists. Right now
the only way to group toplevels is to use app_id, which will end
up grouping too much in case of multiple toplevels with separate
documents. Reporting on the toplevel's parent makes it easy to
distinguish separate window stacks and act accordingly.
The following information through separate events are added:
- make
- model
- serial_number
This should allow clients to identify a display over different sessions and
load configuration data back.
A note is added that the description should be preferred when representing a
display in UI to users but as a short form for example the model could be used
in this case of course too.
Currently, the compositor doesn't have enough information to decide if a
given unmapped layer surface can be rearranged or rather configured.
In order to address the ambiguity, this change adjusts the protocol spec
saying that every client must perform an initial commit without a buffer
attached after creating and setting up a layer surface.
If the compositor knows that the initial state for a specified surface
has not been committed yet, it can skip such a surface when re-arranging
layer shell clients.
This can be used for fullscreening an app from a taskbar, and
potentially also for panels to autohide themselves in case a
fullscreen toplevel appears.
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
