This allows callers to set a destination size different from the
buffer size to scale them.
The DRM backend supports this. The Wayland backend doesn't yet
(we'd need to wire up viewporter).
since wayland doesn't provide a touch id in cancel events, track what
points are active so we can cancel all of them
timestamp is also not provided - use 0 because no one's paying attention
to that anyway
Closes#3000
- Simplifies the backends
- Avoids having two ways to do the same thing: previously one could
disable a layer by either omitting it from wlr_output_state.layers,
or by passing a NULL buffer
- We can change our mind in the future: we can allow users to omit
some layers and define a meaning without breaking the API.
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4017#note_1783997
We've had this struct for a while. It'd be useful for compositors
if they want to manage the swap chains themselves instead of being
forced to use wlr_output's. Some compositors might also want to use
a swapchain without an output.
This is based on previous work [1] [2].
This new API allows compositors to display buffers without needing to
perform rendering operations. This API can be implemented on Wayland
using subsurfaces and on DRM using KMS planes.
Compared to [1], this approach leverages wlr_addon_set to let backends
attach their own private state to layers, removes the pending
state (necessary for interop with wlr_output_commit_state()) and
enum wlr_output_layer_state_field.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/1985
[2]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/3447
This is needed for compositors that want to reserve space for
XWayland panels. Such a feature can be useful in a "transitional"
setup, where only the X11 window manager and compositor is replaced
but other components of an X11 desktop environment are still used.
This change simply reads the X11 property; the compositor is free
to ignore it. Thus, compositors that don't want to support such a
"transitional" feature are not impacted.
v2: Update xwayland_surface_associate()
Instead of destroying all seats, destroy a single one. We only need
to destroy all seats at one call-site (backend_destroy), but we'll
need to destroy a single seat elsewhere in the next commit.
wlr_xcursor_get_resize_name() returns cursor-spec [1] based names
but the default cursor icons shipped in include/xcursor/cursor_data.h
use traditional X cursor names instead.
Compositors that use wlr_xcursor_get_resize_name() to resolve an edge
to a cursor icon name may thus be unable to render appropriate cursor
icons for users that don't have a cursor-spec compliant cursor theme
installed on their system or have it installed in an unusual place.
This patch adds cursor-spec cursor icon name aliases.
[1] https://www.freedesktop.org/wiki/Specifications/cursor-spec/
Since 1d581656c7 ("backend/drm: set "max bpc" to the max") we
set the "max bpc" property to the maximum value. The kernel driver
is supposed to clamp this value depending on hardware capabilities.
All kernel drivers lower the value depending on the GPU capabilities.
However, none of the drivers lower the value depending on the DP-MST
link capabilities. Thus, enabling a 4k@60Hz mode can fail on some
DP-MST setups due to the "max bpc" property.
Additionally, it's not a good idea to unconditionally set "max bpc"
to the max. A high bpc consumes more lanes and more clock speed,
which means higher power consumption and the busy lanes cannot be
used for something else (e.g. other data transfers on a USB-C cable).
For now, let's tie the "max bpc" to the pixel format of the buffer.
Introduce a heuristic to make "high bit-depth buffer" a synonym of
"I want the best quality".
This is not perfect: a "max bpc" higher than 8 might be desirable
for pixel formats with a color depth of 8 bits, for instance when
the color management KMS properties are used. But we don't really
support that yet, so let's leave this for later.
Closes: https://github.com/swaywm/sway/issues/7367
