Keys get virtually "stuck" when using certain modifiers on Windows and Linux/BSD

[Riteo]

Tested versions

• Reproducible in v4.4.beta.custom_build [e549802]

Looking at the git blame, at least for the X11 backend, the core issue is probably very old.

System information

Godot v4.4.beta (e549802) - KISS Linux Community #7 SMP PREEMPT_DYNAMIC Mon Dec 30 07:40:28 CET 2024 on Wayland - X11 display driver, Multi-window, 1 monitor - Vulkan (Forward+) - integrated AMD Radeon Vega 8 Graphics (RADV RAVEN) - AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx (8 threads)

Issue description

A continuation of #100713 and #100879

The keycode field in InputEventKey is supposed to be "unshifted" but this is not the case and from testing this can't be without some other change.

At least the X11 backend disables only the ctrl and shift modifier, leaving the keycode shifted by other modifiers (such as alt gr), if pressed. This confuses the Input backend as some release events are never sent, leaving certain keys in the "keys pressed" set. Notably this affects the new editor popups.

This started when I was trying to debug a side effect of #101848 as, after disabling key shifting for that particular field, the numpad stopped working. I think that this is particularly exacerbated by the fact that the Wayland backend is currently single window only; the X11 backend unpresses any input when focusing any different native subwindow (e.g tooltips).

Hypothetical solutions

We could collect "pressed keys" by their "physical key", as @pcvonz originally implemented in PR #101131 but, as we learned in #99633, a "real" key event is not guaranteed to have a physical keycode associated. @bruvzg also noted on RC that we should probably not depend on keycode so this might be a solution, but we should see how to handle events that do not map cleanly on an american keyboard.

The core issue seems to be the fact that we have the numpad keys mapped "wrong", as in, keycode should, according to the docs, always be the number label, but then how would we represent the various "unshifted" actions (begin, up, page up, right, etc.)? If we were to change that I'm also afraid we'd have compatibility issues.

Supposing this is limited to the X11/Wayland backends, we could filter out all but the "numpad" modifier but there's technically no guarantee about which modifier is which so this would be quite unreliable. Maybe we could just filter alt gr out but then other layouts with yet other modifiers could still cause issues.

I'm not really sure about what would be a good solution; I don't have a very deep knowledge of godot's keyboard handling logic.

Steps to reproduce

Single window mode helps to avoid spurious focus changes from tooltips and whatnot but this can be replicated in multiwindow mode as well.

1. Choose a layout with an alt-gr modifier (e.g. italian);
2. Open the script editor or any other text field;
3. Keep holding alt-gr;
4. Keep holding the à key (see https://en.wikipedia.org/wiki/Italian_keyboard_layout for reference), resulting in #;
5. Release alt-gr;
6. Release à;
7. Now try to trigger one of the new editor popups, as reported in Tooltips stops working after writing code #100713.

Minimal reproduction project (MRP)

N/A

[Riteo]

Update: @bruvzg tested on MacOS, Windows and Linux and it looks like that this issue is the most prominent only on Linux. MacOS does not have this issue (note that it does not have a numlock state), while on Windows the only keys that get stuck are related to the numlock, but from what I can tell that's due to an ambiguity in the way the Key enum is defined in the first place as there is no way of distinguishing the control keys.

I think that if the issue is only related to said ambiguity this should be more or less workable around without too much of an hassle (at least for making Linux/BSD act more like windows), although there's probably still an issue with encoding shifted control keys for more exotic layouts.

[Riteo]

I think I wrote the least comprehensible paragraph possible. This is what I meant:

I just implemented a workaround for Linux/BSD that should hopefully fix every other modifier except the numlock key over at #102169.