If we hit this case, we effectively failed to render something, this might
be because a texture failed to upload or the texture is momentarily
unavailable after a GPU reset. If we fail to render, we have to continue
to track damage for the next frame in hopes that the texture becomes
available then.
An alternative approach would be to fail the commit completely if we
find this case, but in the case of gpu resets, clients may not commit
a new buffer for a while, and a frozen display does not help.
This fixes damage tracking issues after a gpu reset.
We will soon support custom swapchains. In order to track output damage
we should instead use the damage_ring which will hold all the buffers
we are currently tracking anyway across an arbitrary amount of swapchains.
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.
We would fail to call scene_node_update() which would then call output
events for us. We need to make sure to update the node when we first map
a buffer, as the comment explained.
Stop trying to maintain a per-file _POSIX_C_SOURCE. Instead,
require POSIX.1-2008 globally. A lot of core source files depend
on that already.
Some care must be taken on a few select files where we need a bit
more than POSIX. Some files need XSI extensions (_XOPEN_SOURCE) and
some files need BSD extensions (_DEFAULT_SOURCE). In both cases,
these feature test macros imply _POSIX_C_SOURCE. Make sure to not
define both these macros and _POSIX_C_SOURCE explicitly to avoid
POSIX requirement conflicts (e.g. _POSIX_C_SOURCE says POSIX.1-2001
but _XOPEN_SOURCE says POSIX.1-2008).
Additionally, there is one special case in render/vulkan/vulkan.c.
That file needs major()/minor(), and these are system-specific.
On FreeBSD, _POSIX_C_SOURCE hides system-specific symbols so we need
to make sure it's not defined for this file. On Linux, we can
explicitly include <sys/sysmacros.h> and ensure that apart from
symbols defined there the file only uses POSIX toys.
- Add POSIX 1993.09 compliance macro in source files that use
"struct timespec";
- Add POSIX 2001.12 compliance macro in source files that use
"struct sigaction" and the SA_SIGINFO macro, or the fchmod()
function;
- Add POSIX 2008.09 compliance macro in source files that use the
getline() function.
These compliance macros are enough for wlroots to compile with the
git-master version of uClibc-ng.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
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.
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.
