| Summary: | AZERTY keyboard support broken and inconsistent | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Daniel Gibson <metalcaedes> |
| Component: | events | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | major | ||
| Priority: | P2 | CC: | amaranth72, dll, icculus, mickael9, xovni |
| Version: | HG 2.0 | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: | patch for latest SDL2 hg to always map SDL_SCANCODE_[0-9] to SDLK_[0-9] | ||
|
Description
Daniel Gibson
2015-11-22 17:33:16 UTC
oh, to clarify: I was talking about Linux/X11, no idea how Wayland or mir behave. (And I got all the information from other people, mostly https://github.com/dhewm/dhewm3/pull/135 - I don't use AZERTY myself) In case it turns out that we want the windows behavior (just return SDLK_1, SDLK_2, ..., SDLK_9, SDLK_0 for SDL_SCANCODE_1, ..., SDL_SCANCODE_0 for all layouts), I think the easiest way to achieve that for all platforms without touching all the backends is overwriting those mappings at the end of SDL_SetKeymap(). A quick research suggests that those keys are always either numbers or have the corresponding numbers reachable via shift (like on AZERTY), even for more obscure layouts like Dvorak or Neo. So I guess this behavior shouldn't be too surprising for anyone and thus tolerable. Created attachment 2312 [details]
patch for latest SDL2 hg to always map SDL_SCANCODE_[0-9] to SDLK_[0-9]
I wrote a patch that adds the workaround/fix globally in SDL_SetKeymap()
(In reply to Daniel Gibson from comment #2) > In case it turns out that we want the windows behavior (just return SDLK_1, > SDLK_2, ..., SDLK_9, SDLK_0 for SDL_SCANCODE_1, ..., SDL_SCANCODE_0 for all > layouts) Is this actually what we want? I'm not sure that's actually what we want. --ryan. No idea, it works and is not totally surprising, as the numbers are still printed on the keys (usually reachable via shift, though). I guess the alternative is adding SDLK_* constants for those keys; but that way SDL2 applications that use keycodes have to be updated to use those keys (and the fix would be 2.0.4+ only), while my patch would "fix" all SDL2 applications, as long as a recent libSDL2 is installed/used. Pinged the ML again, maybe now people have some more time to think about it and answer :) (In reply to Daniel Gibson from comment #5) > No idea, it works and is not totally surprising, as the numbers are still > printed on the keys (usually reachable via shift, though). SDL apps won't know what the keys are truly labelled as though, which is kind of the point of SDL keycodes. (In reply to Daniel Gibson from comment #5) > I guess the alternative is adding SDLK_* constants for those keys; but that > way SDL2 applications that use keycodes have to be updated to use those keys > (and the fix would be 2.0.4+ only), while my patch would "fix" all SDL2 > applications, as long as a recent libSDL2 is installed/used. To me it seems like SDL is missing some functionality, so of course the functionality would only be usable in SDL 2.0.4+ if it were properly addressed. Apps using SDL can't properly handle those keys as it is right now, and giving the wrong keycodes seems like a bug – so codifying the bug as a feature feels wrong to me. It seems to me that the Windows behavior is wrong on some level, and that SDL-keycodes probably ought to, or should have, mapped to ISO 8859-1 codes as much as possible. Many SDL_Keycode values are already declared to specific ISO 8859-1 codes, via a public header (SDL_keycode.h). It doesn't seem like it'd be that much of a stretch to assume that other values would have had a similar mapping, even if they didn't have written, SDLK_* counterparts. I could see how 'fixing' SDL2/Win32 (to emit language-specific ISO 8859-1 codes) might break some existing, SDL2-based Windows apps, though. One thing I'm not sure of is how much of a problem this would be. I agree with the previous comment, the Windows-specific behavior is simply wrong. Just to quote the wiki about SDL_Keycode: "Values of this type are used to represent keyboard keys using the current layout of the keyboard. These values include Unicode values representing the unmodified character that would be generated by pressing the key, or other constants for those keys that do not generate characters." Sending the 0xE9 unicode character when pressing "é" on an AZERTY keyboard would be the expected behavior (and this is what happens on X11) Perhaps an environment variable could be added to explicitly enable/disable the special handling of the numeric keys (on all platforms)? (In reply to Daniel Gibson from comment #1) > oh, to clarify: I was talking about Linux/X11, no idea how Wayland or mir > behave. The situation is even worse on Wayland: the keycode is always the same as the scancode (as if the keyboard was QWERTY). The text inputs are OK. Should I open another issue? Technically Windows is wrong, but even French people think of those keys as number keys. When we were working on the keybinding UI on World of Warcraft this was a huge debate, and we ended up showing number keys since that's what customers expected. I updated the patch with additional comments and added it, thanks! https://hg.libsdl.org/SDL/rev/27eb9a10002c This is now documented in the header: https://hg.libsdl.org/SDL/rev/fe8057094a5a |