wlr_client_buffer has a bad design: just because it needs some
ref'counting functionality, it's implemented as a wlr_buffer.
Its purpose is to allow compositors to obtain a frozen wlr_texture
to keep painting an old representation of the surface for an
arbitrary amount of time (e.g. during layout reconfigurations).
However a wlr_buffer lock means something else entirely, and abusing
it for ref'counting a texture leads to various issues. In particular,
wlr_surface checks the wlr_client_buffer lock count to decide whether
to mutate a texture on commit. This falls apart if the buffer is
locked for another purpose than freezing a surface texture (e.g.
locked by another wlroots helper). Additionally, wlr_client_buffer
forces backends to re-import and re-check the buffer each time the
client commits, since DMA-BUF wlr_client_buffers are destroyed and
re-created on each commit. wlr_client_buffer also doesn't properly
forward all wlr_buffer operations to the source buffer: some are
unimplemented, and the source buffer is not locked by wlr_client_buffer
thus may be destroyed anytime.
To fix all of this mess, introduce a new struct wlr_surface_texture
whose purpose is just to track whether a wlr_texture is frozen.
Compositors can lock the texture to freeze it. The wlr_buffer can be
accessed from wlr_surface_texture.buffer, or at surface commit time
from wlr_surface.current.buffer.
Use the same logic for cursor FBs as we currently use for primary
FBs. This also fixes the same bug as [1] but in a different, more
robust way.
The new logic integrates better with atomic and will be required
anyways in the future when set_cursor will be superseded by a better
API.
[1]: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4577
Saving the old context and immediately making our own context
current is a common pattern. Let's make it easier to do.
No functional change, just refactoring.
For XWayland surfaces that start maximized, it's best to send an initial
Configure event to set the size of the surface before mapping it. This
reduces visual glitches since the application sees the correct maximized
size when performing its initial layout and drawing.
wlroots surfaces emit their first "map" event after the XWayland window
has already been mapped and the first frame has been drawn & committed.
This is too late to send the initial Configure event.
So, add a new "map_request" event which is emitted immediately before
telling XWayland to map the window. Compositors can connect to this
event to send the initial Configure event to an XWayland app based on
its requested maximized (or fullscreen) state.
Compositors should not place anything visually on the screen at this
point but rather wait until the "map" event as before.
On startup, we fetch the previous MODE_ID blob ID so that
compositors can keep using the previous mode if they want to.
However, that blob doesn't belong to us, it belongs to the
previous DRM master. As a result, we get an error when trying to
destroy it.
Fix this by tracking whether the blob belongs to us or not.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3811
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>
Compositors now are expected to wait for an initial commit by checking
wlr_xdg_surface.initial_commit on every surface commit and send
(schedule) configure events manually.
Since we only use the backend capabilities here we can simply pass
them in directly. This allows other locations to create an allocator
even if they don't have a backend. They can simply specify the caps
they want instead.
Some opaque pixel formats (nv12, p010) require per-plane bytes_per_block
info. However, it doesn't make sense to store them in
wlr_pixel_format_info, as they will never be useful (currently, this
info is used for shm, which doesn't have a concept of multi-planar
buffers.)
Let's define a separate array and function for determining whether a
pixel format has alpha.
