Color transforms are better suited than raw gamma tables, because:
- They don't need to get copied around: they are ref'counted.
- They can represent more color operations (will be useful for the
upcoming KMS color pipeline API, and for the Wayland color
management protocol).
If a surface is mirrored on two outputs, we don't want to pick the
first output if the second has a higher refresh rate.
Also fixes duplicate frame/feedback events when a surface is added
to multiple scenes.
This lets the surface handler decide which output to send frame
callbacks from. The output_sample event already works this way.
Introduce wlr_scene_surface_send_frame_done() as a replacement for
wlr_scene_buffer_send_frame_done() when a compositor doesn't have
an output at hand.
If a surface appears on two outputs with the same intersection
area, or even if a surface appears on an output with a small
intersection area, we want to use the highest scale.
Fixes flip-flop when a surface is added to multiple scenes.
References: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3901
Follow-up from !4803. Make things consistent by making all `struct
timespec`s in events owned. Reduces the need for thinking about
ownership/lifetimes.
We send the output_leave event and destroy a toplevel_output both if our
output_leave listener is called, or if the underlying wlr_output is
destroyed.
We somewhat clumsily reused the output_leave listener, which meant that
even though we had the toplevel output, we went out of our way to let
the output_leave handler find said toplevel_output again.
Simplify both pathways by adding a toplevel_output_leave function.
Should have no functional changes.
If the underlying wlr_keyboard emits duplicated key-presses,
wlr_keyboard_group->keys might not be empty even after calling
wlr_keyboard_group_remove_keyboard() for all of the keyboards.
This reverts commit 86eaa44a3a.
That commit caused a regression for IME users in many compositors:
when a input_method is activated while a key is pressed, and a virtual
keyboard is created by IME, the following key-release event via the
virtual keyboard is missed since the key in the virtual keyboard haven't
been pressed. For example, pressing and releasing Ctrl+F in Firefox with
fcitx5 running triggered repeated keys (ffffff...) in the opened input
box.
If a surface which relies on the default window geometry (e.g. wlroots'
Wayland backend output) gets resized, the geometry doesn't get updated.
This commit fixes that. Additionally, the fallback is the explicitly
set window geometry now, not the extents; this works better for
Chromium.
Preferably, the geometry computation would've been done at the client
commit time, but this requires correct subsurface state management which
we don't have at the moment. The next best solution, which is computing
the geometry on server commit time, doesn't currently have a way to
prevent user commit handlers from firing, meaning that compositors might
get an invalid surface state. Additionally, Chromium and gtk-layer-shell
turned out to violate the protocol in this regard, so client
disconnection leads to really bad UX.
As such, complain via a log message instead, and ignore invalid
geometry, falling back to the bounding rectangle.
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.
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")
