scene_entry_try_direct_scanout returns a tristate value, but the log
message was not updated to account for this.
Compare whether or not the state is specifically SCANOUT_SUCCESS for
logging purposes.
Fixes: c450991c4b
During surface resource cleanup, several signals will be emitted. If any
of these end up calling wlr_surface_send_enter, a new output could be
added to the current_outputs list. This would result in a leaked
surface_output and a dangling wlr_surface pointer.
Clean up current_outputs last.
References: https://github.com/swaywm/sway/issues/8650
Move single-pixel buffer status cache from wlr_scene_surface to
wlr_scene_buffer, it makes more sense there and means the optimisations
will still work if wlr_scene_buffer is used without wlr_scene_surface.
Direct scanout can be enabled and disabled on a frame-by-frame basis,
and so we could end up sending different feedback to a surface on every
other frame. Reacting to new feedback is expensive, as the client may
need to reallocate their swapchain.
Debounce the state change a number of frames, for now set to 30, to
avoid immediate reaction to scanout (or composition) that only lasts a
few frames.
A timer could be used instead, but it did not seem worth the complexity.
What just want to know that the state has been stable across a
reasonable number of samples, and a counter seems sufficient for that.
The single-pixel buffer protocol is used to allow wayland clients to
easily draw solid-color rectangles by presenting a 1x1-pixel buffer and
scaling it to the desired size. This patch improves how these buffers
are then handled in the scene-tree renderer.
We already ignore opaque black rectangles at the very bottom (and
anything under them) because we assume we'll be rendering on a black
background. This patch detects black opaque single-pixel buffers and
handles them in the same way as black opaque rectangles. It also
renders single-pixel buffers as rectangles rather than buffers because
this is probably more efficient in the underlying renderer.
In wlr_scene_surface we cache whether the attached buffer is a
single-pixel buffer. This is done because the
wlr_single_pixel_buffer_v1 will be destroyed after texture upload, after
which it becomes much more annoying to check if the buffer is a
single-pixel buffer.
Add wlr_single_pixel_buffer_v1_try_from_buffer() and move `struct
wlr_single_pixel_buffer_v1` to wlr_buffer.h. This allows other code to
find out if a wlr_buffer is a single-pixel buffer and, if so, find out
what color it is.
The kernel performs some additional checks when
DRM_MODE_ATOMIC_NONBLOCK is supplied: it requires that none of the
planes are still busy with a previous page-flip.
Pass the flag during test-only commits so that we don't end up
performing a commit which will fail.
Ignoring the entire `/subprojects/` directory prevents the next rule
from including just the Meson wrap files. Instead, ignore all the files
in the directory which allows the intended behavior.
We were signaling the release timeline point when the
wlr_client_buffer was released. However, the wlr_client_buffer isn't
necessarily released at the same time as the underlying source
wlr_buffer. For instance, with wl_shm the source buffer is released
before the wlr_client_buffer, and with linux-dmabuf-v1 the source
buffer is released after the wlr_client_buffer. However, we want
to signal the release timeline point exactly at the same time we
send the wl_buffer.release event to the client.
Use surface->buffer->source instead of &surface->buffer->base to
fix this.
linux-drm-syncobj-v1 can only be used with DMA-BUFs, and
wlr_client_buffer.texture will keep the source locked, so
surface->buffer->source is guaranteed to be non-NULL and unreleased.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3940
Fixes: 9e71c88467 ("scene: unwrap wlr_client_buffer for direct scan-out")
The current buffer allocator allocates a buffer that is either the
minimum stage span, the requested size times two, or the largest current
allocation times two.
Imagine needing a miniscule allocation. We currently have 1M, 8M and 16M
buffers, but the 1M buffer is full or not available. The last rule would
cause us to request a 32M buffer, rather than a more appropriate 2M
buffer to fill the bucket sequence.
Make two adjustments to this logic:
1. Round the requested size up to the nearest power of two to avoid odd
bucket sizes.
2. Look through the available buffers and find a hole in the bucket
sequence to fill, which is made easy by the power of two rule above
as we can just iterate until the buffer we are looking at is more
than 2x our current target.
The buffer we create is inserted into the middle of the list of buffers
as needed to maintain the size order.
We expect the render buffers to be ordered largest to smallest, with the
allocator using a reverse iteration to fill smallest buffers first.
Buffers that had been borrowed by a command buffer would just be
inserted at the end of the list, and would not maintain ordering with
any buffers already in that list.
Use a sorted insert to ensure that buffers remain ordered.
Certain signal-related properties, such as the signal mask and handlers
that are set to ignore, are not reset by exec and therefore affect the
new process image.
In case of Xwayland, a compositor setting SIGCHLD to SIG_IGN causes
keyboard compilation to fail as it expects waitpid to work by default.
Reset the signal mask and the two signals that sway is known to set.
