With the Vulkan renderer we don't support implicit modifiers.
However wl_drm only supports implicit modifiers.
Stop advertising wl_drm formats when implicit modifiers are
unsupported.
Query the formats at init time, then forget about the renderer.
This will allow wl_drm to be created with a list of formats instead
of a renderer, and will behave better after a GPU reset.
The backend no longer changes the output state behind the
compositor's back. Instead, compositors can listen to the "commit"
event and check for WLR_OUTPUT_STATE_ENABLED/WLR_OUTPUT_STATE_MODE.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/2300
Some compositors may want to use the linux-dmabuf-v1 implementation
with a completely custom renderer. Add a function to create the
global with a default feedback.
...when only one edge is anchored.
The layer-shell protocol specifies that a positive exclusive-zone value is
'meaningful' if the surface is anchored to either:
1. one edge
2. one edge and both perpendicular edges.
For example, if you wish to position a layer-shell client along the top
edge and make it exclusive, you should be able to either set anchor=TOP or
anchor=TOP|LEFT|RIGHT. It appears that many panels/bars use the latter
approach (anchor to an edge and also both perpendicular edges) which is
probably why this has not been reported previously.
This patch adds support for the first case and thereby makes exclusive
zone behaviour consistent with the protocol and also with sway's extant
layer-shell implementation.
Now, it is checked whether an output pixel corresponds to an integer
number of buffer pixels; if it doesn't, the region is altered to take
this into account.
This allows the backend to have access to the frame damage, as
reported by the scanned-out client. Some KMS drivers can make use
of it (e.g. for PSR, or optimized USB transfers in the GUD driver),
and the Wayland/X11 backends forward it to the parent compositor.
This is a first step towards moving texture uploading out of
wlr_compositor.
This commit allows compositors to opt-out of the texture uploading
by passing a NULL wlr_renderer. An immediate user of this is
gamescope, which currently implements a stub wlr_renderer just to
make wlr_compositor happy.
Fixes
In file included from /usr/include/wayland-server-core.h:32,
from ../types/seat/wlr_seat_pointer.c:6:
In function 'wl_fixed_from_double',
inlined from 'wlr_seat_pointer_send_axis' at ../types/seat/wlr_seat_pointer.c:367:6:
/usr/include/wayland-util.h:641:17: error: 'low_res_value' may be used uninitialized [-Werror=maybe-uninitialized]
641 | u.d = d + (3LL << (51 - 8));
| ~~^~~~~~~~~~~~~~~~~~~
../types/seat/wlr_seat_pointer.c: In function 'wlr_seat_pointer_send_axis':
../types/seat/wlr_seat_pointer.c:329:16: note: 'low_res_value' was declared here
329 | double low_res_value;
| ^~~~~~~~~~~~~
Use a basic linked list to store the currently active mappings.
Note that we don't actually need to implement a full lock-free
atomic linked list here. The signal handler will never write to
the list, it will only read it. Only the main thread will write.
We need to always expose a consistent view of the list to the
signal handler (the main thread might be interrupted at any point
by the signal handler).
This is a re-implementation of wl_shm. The motivations for using
this over the one shipped in libwayland are:
- Properly handle SIGBUS when accessing a wl_buffer's underlying
data after the wl_buffer protocol object has been destroyed.
With the current code, we just crash if the client does that
and then shrinks the backing file.
- No need to fight the wl_shm_buffer API anymore. This was awkward
because we weren't notified when clients created a wl_shm buffer,
and this doesn't play well with our wlr_buffer abstraction.
- Access to the underlying FD. This makes it possible to forward
the wl_shm buffer to a parent compositor with the Wayland/X11
backends.
- Better stride checks. We can use our format table to ensure that
the stride is consistent with the bpp and width.
The concept of a persistent accumulated surface offset is wrong
from a protocol point-of-view. wl_surface.offset is tied to a
commit, its interpretation depends on the surface role.
For example, with the following sequence:
wl_surface@1.offset(1, 1)
wl_surface@1.commit()
wl_pointer@2.set_cursor(wl_surface@1, 42, 42)
The final cursor hotspot is (42, 42): the commit which happened
before the set_cursor request has no impact on the hotspot
computation.
The wlr_output_cursor logic already uses wlr_surface.current.{dx,dy}.
wlr_scene's drag icon doesn't, update it accordingly.
This allows compositors to indicate which features they support,
and is required to eventually make this API stable.
References: https://github.com/swaywm/sway/issues/7260
