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.
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.
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.
This makes it easy for compositors to handle situations where the
DRM or libinput backend becomes unavailable. Compositors can listen
the destroy event of the multi backend returned by
wlr_backend_autocreate() and decide what to do.
