The surface's buffer dimensions were used to scale the clip's x/y
offset. If a surface had a larger buffer than src_box, the calculations
to scale the x/y portion of the clip would be incorrect, yielding
graphical glitches.
This was noticed with Chromium in sway, which during resize uses a
viewport with a src_box to avoid immediate buffer reallocation. While
the viewport was in use, the surface would be shifted so that too much
content was cropped in the upper left, and damage glitching was visible
in the lower right.
Use the buffer source box dimensions instead.
(cherry picked from commit dc7dba8b1f)
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.
Otherwise the number of touch points goes up constantly and d'n'd via
touch can't work as validation always fails.
Fixes 75ecba44 ("seat: add serials to touch up events")
Signed-off-by: Guido Günther <agx@sigxcpu.org>
(cherry picked from commit fef4f3637a)
As struct wlr_drag is destroyed on drop and in the process resets
the focus, a xwayland dnd listener would also reset xwm->drag_focus.
This prevents the xcb replies from being processed and also prevents
the transfer if a compositor would not additionally request new focus
in its wlr_drag destroy handler (which is something usually only done
when in a focus-follows-mouse setting).
This patch creates a new xwm->drop_focus pointer which is a copy of
xwm->drag_focus at drop time. The xcb reply handler and transfer
logic now use the new xwm->drop_focus for their authorization checks.
(cherry picked from commit 546c5d000d)
The wlr_drag takes care of resetting the focused wlr_surface when
it's destroyed, however we store the wlr_xwayland_surface, which
may be destroyed before.
(cherry picked from commit c7acfe906b)
drmModePageFlip() will fail with EBUSY on a disabled CRTC.
We can't fix this by clearing the DRM_MODE_PAGE_FLIP_EVENT when
performing a commit which disables CRTCs, because some device-wide
commits might also page-flip other enabled CRTCs (and skipping the
page-flip event would mess up our buffer tracking).
Fix this by immediately completing page-flips which disable a CRTC
on the legacy uAPI.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3918
(cherry picked from commit 3e651b4642)
Fixes on-screen corruption when displaying a fullscreen client
with an implicit modifier on the secondary GPU.
What happens here:
- Client allocates a buffer with an INVALID modifier on primary GPU.
- Compositor attempts to scan-out this buffer on an output connected
to secondary GPU.
- Buffer is imported to secondary GPU, and is interpreted as if it had
the secondary GPU's implicit tiling, even though it has the primary
GPU's implicit tiling.
We need to forbid cross-device imports with implicit modifiers.
The mgpu_formats list is stripped from any INVALID modifier so
checking that fixes the bug.
Using the mgpu_formats list has an additional benefit: the buffer
is rejected in the test commit if it doesn't have a format supported
by the multi-GPU renderer.
Requires this Mesa bugfix:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31725
(cherry picked from commit c6dd5e3c2e)
This fixes the memory leak in wlr_keyboard_group.keys. The leak happened
because wlr_keyboard.keycodes never contains duplicated keycodes while
wlr_keyboard_group.keys can, so calling wlr_keyboard_finish() for all
the wlr_keyboards in wlr_keyboard_group doesn't always free all the keys
in wlr_keyboard_group.keys.
(cherry picked from commit e21899037a)
We were always creating a custom mode object when the output didn't
have a fixed mode. This is important to handle two cases:
- Virtual outputs with no concept of fixed modes.
- DRM outputs with a list of fixed modes but with a custom mode set.
However, in the case where an output didn't have a fixed mode and
was disabled, we were also creating the custom mode object. Clients
would then see a "ghost" mode: a mode object with no properties at
all.
Fix this by only creating the custom mode object if the output is
enabled.
Fixes: 5de9e1a99d ("wlr-output-management: Send custom modes to clients")
Closes: https://github.com/swaywm/sway/issues/8420
(cherry picked from commit 2c3053370c)
Currently the headless backend does not actually implement the
wlr_output_test function, causing tests containing output state
unsupported by the headless backend to succeed while committing the same
state will always fail.
This commit fixes that by actually hooking up the already exisiting test
function.
References: https://codeberg.org/river/river/issues/1154
(cherry picked from commit da8f7a07ba)
We were checking whether the damage region was empty before
clipping. However a non-empty damage region can become empty after
clipping. Instead, check whether the clipped region is empty.
Fixes: 4339c37f99 ("backend/drm: clip FB damage")
(cherry picked from commit e8e76dc295)
If we are trying directly scan-out a shm buffer, we create a temporary
buffer pool to instantiate a wl_buffer from, created in accordance to
our buffers size. If the buffer has an offset, it will end up out of
bounds of the created pool.
Extend the temporary pool by the buffer offset to compensate. Matching
the original pool size does matter unless we want to optimize away the
temporary pool to reduce mappings in the parent compositor.
(cherry picked from commit 63fabecee2)
The spec for VkMemoryPropertyFlagBits says:
> device coherent accesses may be slower than equivalent accesses
> without device coherence [...] it is generally inadvisable to
> use device coherent or device uncached memory except when really
> needed
We don't really need coherent memory so let's not require it and
invalidate the memory range after mapping instead.
Closes: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3868
(cherry picked from commit 52dce29e06)
The page_flip can be destroyed, but it is unconditionally accessed later
on when setting present_flags. Fix this by simply setting the
present_flags before the page_flip gets destroyed.
(cherry picked from commit 3d2f09bace)
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
(cherry picked from commit 14e1987f50)
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.
(cherry picked from commit 147c5c37e3)
Previous logic could lead wlr_wl_backend.drm_render_name being written
to twice, causing a memory leak. This commit fixes the race condition.
(cherry picked from commit 3103ea3af9)
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.
(cherry picked from commit adf9d8b0be)
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
(cherry picked from commit de574ac098)
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
