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.
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)
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)
This will let compositors know if changing adaptive_sync state has any
chance of working. When false, then the current state is the only
supported state, including if adaptive_sync is currently enabled as is
the case for Wayland and X11 backends.
When true, changing state might succeed, but no guarantee is made. It
just indicates that the backend does not already know it to be
impossible.
This commit fixes the following interaction:
1) The host compositor sends a configure sequence for an output.
2) Before handling it, the guest compositor disables and immediately
re-enables the output.
3) The guest compositor tries to ack the configure event from step 1
which isn't relevant anymore after unmapping and re-initialization.
Instead, ignore all configure events after unmapping until we're sure
the host compositor has processed the unmapping.
Also see
https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/108.
- Reset all variables representing an initialized xdg_toplevel's state
on unmap.
- Send an initial commit only when an output is about to be enabled.
- If an output isn't configured yet, don't commit a buffer.
It's cumbersome for compositors to guard every
wlr_color_transform_ref() or wlr_color_transform_unref() call
behind a #if WLR_HAS_COLOR_MANAGEMENT. Moreover, none of the LCMS2
types are used in our public API.
Instead, always install the color.h header, and add a stub for
wlr_color_transform_init_linear_to_icc().
Since wlroots almost always significantly breaks API each minor release,
allowing parallel installation of wlroots helps packagers deal with
programs that require conflicting versions of wlroots.
Closes: #3786
This has been introduced way back in
be297d9d14 but is never used anywhere.
If compositors want to save the old dimensions before reacting to a
fullscreen or maximize event they can just grab the sizes within their
event handlers instead.
This change makes it possible to support both the direct srgb-format
pipeline and indirect (color-managed, or non-srgb-format) pipeline
for the same render buffer.
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.
