This patch introduces a new protocol proxy, which multiplxes Wayland
clients into a single connection, allowing us to redirect calls (e.g.
create toplevel -> create subsurface). Mixed with some state tracking
and emulation, we can embed a full-featured client into the editor.
Fixes a timing issue where dialogs got configured right before having
their parent set. This gave compositors the time to resize/rearrange the
dialog as if it were a normal window, only to be marked as "floating"
right away. On niri, this manifested as huge dialog windows.
This is achieved with the addition of a `p_parent_id` parameter to
`window_create`, akin to its popup counterpart.
`window_create` now also accepts a single `Size2i` parameter instead of
two integers, in line with the rest of the `WaylandThread` API. The
original idea was to have a very "barebones" API, akin to the `drivers/`
directory, but that didn't pan out.
This race condition made me pull my hair. `wl_display_roundtrip` has its
own little event loop, which apparently conflicts hard with the
always-running event loop thread.
I kinda assumed that it would be thread-safe thanks to its internal
`wl_display_prepare_read` call that the docs talk about but that's
clearly not enough.
Luckily this method is called very few times and the only dangerous
instances are in the initialization routine, which first starts the
thread and then does various roundtrips. Libdecor has also some internal
roundtrips of its own which would often fail. Starting the thread after
all initialization fixes the issue.
Tested this by spamming *lots* of `wl_display_roundtrip` in
`WaylandThread::init()` with and without this fix.
The `Vector2i` division operator casts doubles down to `int32_t`. It
would thus truncate the fractional scale factor to 0 if less than 1,
resulting in a FPE on x86_64.
Fixup to "Wayland: Check selection devices before using them"
This slipped under the radar... until for some reason optimized builds
started crashing, perhaps due to timing-related shenanigans, no idea.
Related #106229. The cursor-shape protocol allows us to not have to deal with cursor theming and instead depend on the
compositor for it.
This still does not quite solve the issue when the compositor doesn't implement the protocol
(or running under the x11 backend) but for gnome/kde and a few more this should resolve things.
This issue came from the frame-based refactoring done in the multiwin
PR.
It looks like some (all?) compositors group certain events alongside
`wl_pointer::leave`, which I absolutely did not expect. The docs don't
seem to mention it either from what I can tell.
We now fall-back on the old pointed window if and only if the current
window is invalid and the old one isn't. Each state fetch is guarded
with an `ERR_FAIL_NULL` so this should still catch any potentially
corrupted window with missing data but a valid ID.
I also added the usual big comment so that this "quirk" does not get
lost to time.
In #101774, some libdecor-specific code was added, but without adding the guards. This broke the build with
`libdecor=no`.
Add `#ifdef` guard as necessary.
Before, the WSI was unfortunately quite broken and we had work around it
by manually pacing frames. Needless to say it was not an ideal solution.
Now, the WSI can make use of the new fifo_v1 protocol to work properly.
If it's available, we'll trust the WSI by disabling manual frame pacing.
While we're at it, let's clean up the suspension code a bit by removing
some duplicated stuff and handling the suspension state through a switch
case.
Multiwindow support simplified input handling by processing all data
only during a `wl_seat::frame` event, which got introduced in wl_seat
version 5. If the compositor reports an older version, we manually call
the frame event handler.
The backend is now mature enough to not explode with multiple windows
but the `DisplayServer` API still cannot meet some guarantees required
by the various Wayland protocols we use. To meet those guarantees this
patch adds three new elements to the DisplayServer API, with relative
handling logic for `Window` and `Popup` nodes:
- `WINDOW_EVENT_FORCE_CLOSE`, which tells a window to *forcefully*
close itself and ensure a proper cleanup of its references, as Wayland
enforces this behavior;
- `WINDOW_FLAG_POPUP_WM_HINT`, which explicitly declares a window as a
"popup", as Wayland enforces this distinction and heuristics are not
reliable enough;
- `FEATURE_SELF_FITTING_WINDOWS`, which signals that the compositor can
fit windows to the screen automatically and that nodes should not do
that themselves.
Given the size of this feature, this patch also includes various
`WaylandThread` reworks and fixes including:
- Improvements to frame wait logic, with fixes to various stalls and a
configurable (through a `#define`) timeout amount;
- A proper implementation of `window_can_draw`;
- Complete overhaul of pointer and tablet handling. Now everything is
always accumulated and handled only on each respective `frame` event.
This makes their logic simpler and more robust.
- Better handling of pointer leaving and pointer enter/exit event
sending;
- Keyboard focus tracking;
- More solid window references using IDs instead of raw pointers as
windows can be deleted at any time;
- More aggressive messaging to window nodes to enforce rects imposed by
the compositor.
This fixes once and for all the core issue of different Godot `keycode`s
released from the same raw XKB keycode.
The `InputEventKey` `keycode` value _should_ map to the "unmodified"
key, but unfortunately there's an ambiguity with their encoding for
"special" keys ("delete", "insert", etc.), in witch they ignore their
unicode representation. This means that a key that is special when plain
but a character when modified would never be properly picked up, so we
do indeed change its keycode. As a consequence of this exception, some
Godot keys never receive release events and get "stuck".
This patch adds an extra check through an `HashMap` to "unstuck" keys
that changed while having the same keycode.
I also could not resist simplifying a bit the regular key event
generation method but this makes things more consistent and predictable
IMO.
There were two edge cases in the frame waiting logic (aka manual frame
throttling or emulated vsync) which would cause the editor to stall in
one way or another:
1. Waiting right after starting the editor would cause a deadlock
between both threads until something happened in the Wayland event
queue, in turn unblocking the Wayland thread and kickstartin the whole
thing;
2. Starting the editor (and probably other long-loading stuff) without
low consumption mode would suspend the window and never commit its
surfaces, thus never signaling the compositor that we want frame events.
The `keycode` field of `InputEventKey` is supposed to be "unshifted";
That is, what the key would output if no modifier keys were pressed.
This should match what's written on the key label, but `Key` enumerates
also all keypad keys, which require a modifier. We thus require some
extra checks for them.
Note that this can still allow "stuck keys", but that's an even deeper
problem.
The v1 version is deprecated and bound to be removed in the future from
all compositors. This patch adds a v1/v2 designator to everything
related to the protocol and prefers the v2 protocol if both are
available.
Additionally, renames the event handler to follow the Wayland interface
name, for consistency with the rest of the codebase.
