Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

InputKey does not use the correct keys when the keyboard layout is not QWERTY #5767

Open
MatthieuHernandez opened this issue May 2, 2023 · 3 comments · May be fixed by #5790
Open

InputKey does not use the correct keys when the keyboard layout is not QWERTY #5767

MatthieuHernandez opened this issue May 2, 2023 · 3 comments · May be fixed by #5790
Assignees
Labels
area:input priority:1 Very important. Feels bad without fix. Affects the majority of users.

Comments

@MatthieuHernandez
Copy link

MatthieuHernandez commented May 2, 2023

I will explain with a simple example.
I used a AZERTY keyboard and I wand to do an undo on the map editor.
On this line, it is said that the undo action is on Ctrl + Z (which is also the normal shortcut on an AZERTY keyboard)

new KeyBinding(new KeyCombination(InputKey.Control, InputKey.Z), PlatformAction.Undo),

But on Osu!(lazer) I need to press Ctrl + W (as if my keyboard was forced to QWERTY).
The Z and W keys are reversed between QWERTY and AZERTY.

The weirdest thing is that I don't have the problem on osu!(stable).

I think the problem is related to this ppy/osu#11143.

P.-S I don't have the problem when I write text in osu! or when I maps my keys in the key configuration.

EDIT: The issue seems come from the InputKey.cs which hard-codes values.

@MatthieuHernandez MatthieuHernandez changed the title InputKey does not use the correct keys on keyboards other than QWERTY InputKey does not use the correct keys when the keyboard layout is not QWERTY May 2, 2023
@MatthieuHernandez
Copy link
Author

MatthieuHernandez commented May 2, 2023

I just found the exact source of the issue.
In the file SDL2Extensions.cs for the mapping of the keys, it is used SDL.SDL_Scancode which maps the keys by position on the keyboard and not by symbol.
See the SDL documentation: SDL2/CategoryKeyboard.

The solution is simple, it consists in replacing all SDL_Scancodes by SDL_Keycodes but...

⚠️ This change could have unwanted consequences for some users that might be difficult to predict.

@peppy
Copy link
Member

peppy commented May 3, 2023

This seems pretty critical to get fixed.

@peppy peppy added area:input priority:1 Very important. Feels bad without fix. Affects the majority of users. labels May 3, 2023
@Susko3 Susko3 self-assigned this May 12, 2023
@MatthieuHernandez
Copy link
Author

Hello @Susko3, I already made a Pull Request for this, can you please review it?
Hopefully it will help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:input priority:1 Very important. Feels bad without fix. Affects the majority of users.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants