I ported the new softclass macro too blindly. Apparently the various
window messages did not cast properly, skipping some important "deleted
window" checks.
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.
We should only include the vendored headers for Wayland and libdecor-0 when
we use `so_wrap`, i.e. when we *don't* build against system libraries.
The libdecor-0 pkg-config file includes the `libdecor-0/` prefix already,
so its header should be included without it, and likewise in our so wrappers.
Fixes#102671.
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.
Images don't have RIDs and this way of checking stuff broke the cursor
cache. Let's do like all other platforms and check the resource
reference instead.
Before, we would check both methods together, leading to loops.
Now we track the actual reason we suspended and only unsuspend when
that same reason triggers. For example, if we suspend because of the
suspended flag we'll unsuspend only because it got unset. Conversely, if
we suspend because of a timeout we'll unsuspend only if we get a new
frame event.
We do this because, while some compositors properly report a "suspended"
state (hinting us to stop repainting), most don't and we need a "safety
net" anyways as we do not want to constantly stay at 1fps (the max time
we'll wait before giving up) either.
