We've actually been doing the wrong thing this whole time, for v1 of the
protocol, we should set the refresh_nsec field to 0 if the output does
not have a constant refresh rate. However we've been setting it to the
fastest rate instead since eac7c2ad2f
which is incidentally exactly what v2 of the protocol proposes.
So allow advertising v2, and fix v1 to set refresh_nsec to 0.
This implements the new ext-foreign-toplevel-list-v1 protocol [1].
Implemented analog to the zwlr-foreign-toplevel-management-v1 implementation.
The additional _ext_ in the names was added to avoid name collisions.
[1]: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/187
Co-authored-by: Leon Henrik Plickat <leonhenrik.plickat@stud.uni-goettingen.de>
Implement a basic version of linux-dmabuf-unstable-v1 version 4.
Only default hints are implemented.
The new wlr_linux_dmabuf_feedback_v1 data structure will allow
compositors to define their own custom hints in the future. This
data structure makes it easy to describe feedback metadata.
It's converted to a "compiled" form suitable for marshalling over
the Wayland socket via feedback_compile.
This is Mesa's legacy wl_drm protocol. It will eventually get replaced
with linux-dmabuf, however right now it's the only way to get the DRM
device used by the parent compositor.
The keyboard shortcuts inhibitor protocol is useful for remote desktop
and virtualization software in order to request all keyboard events to
be passed to it and (almost) none being resonded to by the compositor.
This allows the session at the other end of the remote desktop
connection or inside the virtual machine to be interacted with as usual
(e.g. Alt+Tab to switch windows on the remote system instead of
locally).
Add the wayland protocol to the meson build files.
Copy'n'search'n'replace the very similar idle inhibit protocol
implementation. This already provides all the basic functionality:
- creating and destroying inhibitors upon request by a client,
- destruction in reaction to destruction of surfaces or displays,
- a list of inhibitors to search through for existing ones as well as
- a signal to be sent to the compositor upon registration of a new
inhibitor.
Beyond that we add the active and inactive events to be sent to the
client and wire those to activate and deactivate functions for the
compositor to call in confirmation of activation of a new inhibitor or
(un-)suspending of an existing inhibitor e.g. in response to a special
key combination entered by the user as suggested by the protocol.
As mandated by the protocol, we check the existance of an inhibitor for
a given surface and seat upon creation and return the error provided by
the protocol for that purpose.
Signed-off-by: Michael Weiser <michael.weiser@gmx.de>
Closes: https://github.com/swaywm/wlroots/issues/1817
