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.
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.
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.
Godot checks if there's Vulkan or GLES3 support.
If no support is found, it shows an error message.
However the code for this error message is left out when building with
opengl3=no
Initially the WaylandThread cursor code was supposed to be as stateless
as possible but, as time went on, this wasn't possible.
This expectation made the resulting API quite convoluted, so this patch
aims to simplify it substantially bot in terms of API surface and, most
importantly, in terms of actual implementation complexity.
This patch also fixes custom cursors since I accidentally changed the
mmap flags to MAP_PRIVATE some time ago. This took me hours to notice.
While experimenting with the recent "extent to title" PR, I noticed that
it's not guaranteed for a "button released" event to be emitted when
the pointer leaves the main surface, leaving some buttons stuck.
Not doing this for tablets since the spec makes this behavior clear and
explicit, so we (hopefully) shouldn't have this issue there.
