ohrrpgce icon indicating copy to clipboard operation
ohrrpgce copied to clipboard

Key mapping problems on non-US keyboard layouts

Open rversteegen opened this issue 1 year ago • 0 comments

Refiling this issue to start afresh, replacing #785 which is entirely obsolete and irrelevant discussion.

Although text entry should work, key mapping for key combos can still be quite broken. A specific example is pressing + to e.g. add a slice or a map layer: on a German keyboard using gfx_sdl2 you have to press the ´ key (left of backspace, where + is on a US keyboard), or press numpad +.

Aside from mappings, we also make incorrect assumptions about which symbols share keys or not. The < > [ ] { } , . keys are the biggest problems. E.g. on a German keyboard < and > are on the same key, a key that doesn't even exist on a US keyboard! So if we respected the actual keycaps for the user's layout they might have to press Shift/Alt/Fn to access some keys. That's a change we might want to make just in Custom, not Game. Although I'd struggle to find any games that'd be affected. Maybe a couple of roguelikes that use the ? key?

The ability for users to remap controls in Custom would be very nice and would let people replace awkward controls like having to press Shift-< to input > to e.g. change palette colour, but that's a separate feature. Key combos should just work, pressing Shift/Alt/Fn as needed, without having to remap anything.

Part of this problem is gfx_sdl2 specific (I haven't tested the others yet): gfx_sdl uses the key-symbol-based SDLKey while gfx_sdl2 uses the key-location-based SDL_Scancode, and I don't remember why I made that change, maybe because I thought it was closer to the behaviour of QB and FB or maybe because it caused mapping problems when holding Shift? It's likely gfx_sdl2 should switch to using SDL_Keycode but doing so might break other things.

SDL2's SDL_keysym included in key events provides the SDL_Scancode (SDL_SCANCODE_* constants), which tells the physical location on the keyboard with reference to a US keyboard layout, and the SDL_Keycode (SDLK_* constants). In many cases the SDL_Keycode is equal to the non-decomposed unicode character for that key. SDL 1.2 is bit different. SDL 1.2's SDL_keysym has the raw 8-bit scancode (no constants provided), the virtual SDLKey sym (SDLK_* constants), and the corresponding unicode character.

rversteegen avatar Dec 06 '23 00:12 rversteegen