When attaching more than one cursor to wlr_output, the first one
will pick the output's hardware cursor, then for the second one
output_set_hardware_cursor() would fail (since the hardware cursor
was already taken), but we still ended up resetting the current
hardware cursor (by calling output_disable_hardware_cursor() below).
As a result only the second cursor would be displayed.
To fix this, move the current hardware cursor check to the caller.
Fixes: 510664e79b ("output: disable hardware cursor when falling back to software")
(cherry picked from commit fd069ad4f2)
Upon leasing, the wlr_drm_lease_connector_v1 will be automatically clean up by the wlr_output
destroy handler. There is no need for the wlr_drm_lease_manager to keep track of leased connectors.
(cherry picked from commit 0166fd9eb7)
During suspend, we first disable output and then remove the input device.
This causes cursor->state->surface released while cursor->texture leaves.
Which leads to use-after-free after resume.
(cherry picked from commit be5e266211)
When we fail to render the cursor (in my case because the cursor is too
large) we bail out of the output_cursor_attempt_hardware function. This
causes output_cursor_set_texture to clean up after us, but we've already
cleared the hardware_cursor, and so output_disable_hardware_cursor
thinks we don't have a hardware cursor to disable.
We shouldn't modify the hardware_cursor variable before we've
successfully changed the hardware cursor, this way the caller can clean
up after us like it expect to.
This was brought up by an actual bug when playing the game Kaizen. Which
uses oddly sized cursors, that fell back to software cursors for me, and
left the hardware cursor hanging around. This change has been tested to
fix that.
During the testing of this change, I have noticed that the previous code
worked fine the first time the cursor was switch to software. It only
failed on subsequent attempts. I haven't figured out why that is.
(cherry picked from commit 07e92fb868)
This fixes a `wl_list_remove()` from an uninitialized listener
when using `wlr_transient_seat_v1_deny()` in a `create_seat`
handler.
(cherry picked from commit c39b3ce7a3)
We cache whether buffers are single-pixel buffers (and if so what color
they are) to allow rendering optimizations. But this breaks if the
client changes out the single-pixel buffer for one with a different
color, because this updates the texture in-place instead of actually
changing the buffer.
We can fix this by blocking in-place texture updates for single pixel
buffers.
Original bug: https://codeberg.org/ifreund/waylock/issues/121
See also: !5092
(cherry picked from commit 58c3680d96)
Commit b4ce0d8b39 ("render/egl: accept negative DRM FD to select
software rendering") added an EXT_device_drm check to figure out
whether the user selected a device with a DRM FD or without one.
However, for KMS-only devices, Mesa will never advertise the
selected KMS node:
3f1d40d230/src/egl/main/egldevice.c (L109)
Instead, pass down a parameter to indicate whether a DRM FD was
passed in.
Fixes: b4ce0d8b39 ("render/egl: accept negative DRM FD to select software rendering")
(cherry picked from commit 48bd1831fe)
Currently if both box_a and box_b are non-empty but do not intersect,
this function does not set dest to an empty box. This contradicts the
doc comments and is surprising for users.
(cherry picked from commit f5e7caf599)
The spec says [1]:
> If set, the Window Manager should use this in preference to WM_NAME.
However we overwrite WM_NAME with NULL when _NET_WM_NAME is unset.
Fix this by storing both WM_NAME and _NET_WM_NAME, so that we
handle properly all combinations of events (e.g. a client setting
both and later clearing one).
[1]: https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html#id-1.6.2
With labwc and WLR_DRM_FORCE_LIBLIFTOFF=1, a segfault is seen on startup
because we call output_state_get_buffer_src_box() when there is no
buffer set in the output state. Fix this by getting the src/dst box
from state->primary_viewport instead.
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.
This reverts commit 954dba3968.
Motivations:
- This only resets some state, but other global state such as other
signal handlers, process limits (e.g. NOFILE) or system-specific
settings are left as-is. The chunk of state which does get reset
is opinionated.
- Compositors have other ways to do this, e.g. with pthread_atfork()
or with empty signal handler callbacks.
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.
