This fixes direct scanout VRR. As direct scanout buffers are not part
of the swapchain, we would mistakenly union instead of subtract the damage
meaning it will just accumulate indefinitely.
The reason for this existing in the first place is for compositors that
might want to sidestep scene and commit their own buffers to the output.
In this case, scene could theoretically acknowledge that and update the
damage. Except, this really didn't work because WLR_OUTPUT_STATE_DAMAGE
would need to be defined which is optional. This patch also properly
acknowledges commits without damage.
In the use case of a weird compositor that might want to sidestep scene,
they can just trash the damage ring themselves.
Fixes: #3871
There were two problems with the old implementation:
1. wlr_scene_output_commit would bail early if a frame wasn't requested
and there was no commit damage, however commit damage could never accumulate
until rendering happens. The check was subtly wrong as a result.
2. Previously, we would fill the pending commit damage based on the
current state of the damage ring. However, during direct scanout, the
damage would accumulate which would mean we would submit damage from
previous frames even if we didn't need to.
This commit removes extra wlr_xdg_toplevel_set_parent() calls,
simplifies wlr_surface->wlr_xdg_toplevel conversion logic, makes related
structures store wlr_xdg_toplevel objects directly instead of
wlr_surface objects, and improves the code style.
Without this patch, a client calling handle.destroy() will trigger
an assert in libwayland due to a NULL pointer for the destroy handler.
Also implement a missing .destroy handler for the manager itself
and delay destruction of the manager resource from the .stop handler
to the .destroy handler.
This fixes two problems:
- A surface could get unexpected release events for buttons pressed
while other surface was focused;
- Clearing focus while a button is pressed would lead to the button
getting "stuck".
Fixes: 8730ca9661
The old logic might not update the entire scene node when a node is
disabled. It would only consider the damage last time (the damage was
based on the visible region of the node).
It's important that we update the entire node region because xwayland
stacking will depend on this.
From the event description:
This event indicates that the output power management mode control is no
longer valid. This can happen for a number of reasons, including:
<...>
- The output disappeared
This swaps the argument order of wlr_surface_accepts_touch() and
wlr_surface_accepts_tablet_v2(), putting the wlr_surface argument first
as should be the case for functions namespaced with wlr_surface_*.
We were relying on the fact that we wouldn't paint anything on top
of the black background in the region of a black rect. However
when fractional scaling is used the repaint region might get
expanded to nearby pixels by scale_output_damage(). As a result
the neighbour scene nodes might leak into the skipped black rect's
region.
Avoid this by using this optimization for bottom-most black rects
only when fractional scaling is used.
References: https://github.com/swaywm/sway/issues/8233
If we need to apply a color transform to rendered content, we will not
be able to use direct scanout. Explicitly skip it to not accidentally
show frames lacking the color transform.
The DRM backend's set_cursor function always return true if the
buffer is NULL. If using a NULL cursor's buffer on startup, the
wlr_output_cursor will be marked as a hardware cursor. If the
cursor later gains a non-NULL buffer and the DRM backend rejects
that buffer, the cursor will remain marked as a hardware cursor,
despite the backend not displaying it as such. As a result, the
cursor will not be displayed at all. Fix this by always resetting
the hardware_cursor field in output_cursor_attempt_hardware().
Instead of having separate getters for shm formats and DMA-BUF
formats, use the same pattern as wlr_output_impl.get_primary_formats
with a single function which takes buffer caps as input.
Clients may, for example, commit an exclusive zone larger than the
output dimensions. Compositors must handle this gracefully, which likely
requires more work on the compositor side but returning a usable area
with negative width or height in wlr_scene_layer_surface_v1_configure()
is nonsensical.
When a wlr_gamma_control client calls set_gamma, we allocate a LUT based
on the value returned from wlr_output_get_gamma_size at the time of the
call.
If the output is off and has no CRTC, such as if gamma changes in the
background while a display is disabled for idle reasons,
wlr_output_get_gamma_size returns 0. This leads to a zero-sized table,
which the drm backend interprets as a request to reset gamma tables to
their default.
Store the gamma size when the gamma control was created. Even if the
size changes, this is the size the client was sent and uses to create
the LUTs it sends.
The surface argument is only used to obtain a wlr_seat_client and
semantically makes no sense. The wl_touch.cancel event applies to all
touch points and all surfaces of a client.
I decided to make the functions accept a wlr_seat_client rather than a
wl_client as it is directly available in the wlr_touch_point struct and
simplifies the implementation.
Previously, cases when a viewport source box was updated without attaching
a buffer weren't checked for correctness properly because the state's buffer
would be NULL. Use wlr_surface_state_has_buffer() instead.
This is worth doing despite wl_client_get_destroy_listener() incorrectly
accepting a mutable wl_client pointer since this lookup_client()
function will primarily be used with a wl_display_global_filter_func_t
which only provides a const wl_client pointer.
Work around this libwayland API wart in wlroots so compositors don't
have to.
I wish to use a allowlist of globals for my security context
implementation rather than a blocklist, which means I need access to
the wp_single_pixel_buffer_manager_v1 global in order to allowlist it.
I think using a allowlist will make it harder for me to accidentally
expose globals to a security context that were meant to be restricted.
I wish to use a allowlist of globals for my security context
implementation rather than a blocklist, which means I need access to
the ext_idle_notifier_v1 global in order to allowlist it.
I think using a allowlist will make it harder for me to accidentally
expose globals to a security context that were meant to be restricted.
I wish to use a allowlist of globals for my security context
implementation rather than a blocklist, which means I need access to
the wl_shm global in order to allowlist it.
I think using a allowlist will make it harder for me to accidentally
expose globals to a security context that were meant to be restricted.
This new helper assists compositors in allocating buffers for
modesets. It degrades to different allocation parameters as
needed, and should help with screens not turning on when multiple
outputs are connected on some hardware (e.g. Intel).
For simplicity, the old logic to try allocating with explicit
modifiers first and then fallback to implicit modifiers later is
left as-is. We'll probably want to have more complicated logic
instead in the future: try the fallback on one output at a time,
and try dropping modifiers one by one instead of using implicit
modifiers (at the cost of some combinatorial explosion).
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/1873
Co-authored-by: Kenny Levinsen <kl@kl.wtf>
This allows us to remove the renderer destroy listener. The
listener was buggy: compositors can't destroy surface resources on
their own.
The wlr_compositor will always outlive the wlr_surface, so no need
for a destroy listener.
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.
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.
Alexander Orzechowski
Kirill Primak
Consolatis
Simon Ser
Isaac Freund
Kenny Levinsen
JiDe Zhang
groveer
Manuel Stoeckl
Ilia Bozhinov
Vaxry