This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• patch for latest SDL2 hg to always map SDL_SCANCODE_[0-9] to SDLK_[0-9] (sdl2_azerty_fix.patch, text/plain, 2015-11-23 01:04:22 +0000, 895 bytes)

Reported in version: HG 2.0
Reported for operating system, platform: All, All

Comments on the original bug report:

On 2015-11-22 17:33:16 +0000, Daniel Gibson wrote:

AZERTY keyboard layouts (which are the default layouts in France and Belgium) don't have the number keys (1, 2, ..., 9, 0) in the first row of keys, but ², &, é, ", ', (, -, è, _, ç, à, ), = (with small differences between the France and Belgian variants). Numbers are reached via shift.

On Linux and OSX, SDL seems to use the corresponding ISO 8859-1 codes (231 for ç, 232 for è etc) as SDL_Keycode (but no SDK_* constants exists for those values!), while on Windows SDL seems to map those keys to SDLK_1, SDLK_2 etc, like you'd get on QWERTY.
I don't know how other platforms behave.

So we have two problems:

1. At least on Linux and OSX invalid/undefined SDL_Keycodes are returned
2. Different platforms behave differently (Windows vs Linux/OSX)

It's unclear what behavior is desired: Should SDL_* constants for those keys be introduced (and Windows behavior changed accordingly)?
Or should all platforms behave like Windows here and use the existing SDLK_1, ..., SDLK_0 keycodes?

This bug on the mailing list:
https://forums.libsdl.org/viewtopic.php?t=11555 (my post about Linux/Windows)
https://forums.libsdl.org/viewtopic.php?t=11573 (Tim Walters discovered the same problem on OSX about 1.5 weeks later).

On 2015-11-22 18:21:06 +0000, Daniel Gibson wrote:

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 dhewm/dhewm3#135 - I don't use AZERTY myself)

On 2015-11-23 00:44:24 +0000, Daniel Gibson wrote:

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.

On 2015-11-23 01:04:22 +0000, Daniel Gibson wrote:

Created attachment 2312
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()

On 2015-12-29 01:39:35 +0000, Ryan C. Gordon wrote:

(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.

On 2015-12-29 01:58:53 +0000, Daniel Gibson wrote:

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 :)

On 2015-12-29 02:06:38 +0000, Alex Szpakowski wrote:

(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.

On 2015-12-29 03:10:40 +0000, David Ludwig wrote:

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.

On 2017-03-17 00:01:22 +0000, Mickaël Thomas wrote:

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)?

On 2017-05-30 00:57:12 +0000, wrote:

(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?

On 2017-08-12 22:43:33 +0000, Sam Lantinga wrote:

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

On 2017-08-12 22:46:05 +0000, Sam Lantinga wrote:

This is now documented in the header:
https://hg.libsdl.org/SDL/rev/fe8057094a5a