Wrong keyboard scan codes in Emscripten

[KivApple]

If you have non-QWERTY keyboard (e. g. French AZERTY) you will get wrong scan codes in SDL_KeyboardEvent while running your code compiled with Emscripten in browser. There are no such problem while running your application natively (tested on Windows and Mac OS X). Also this website https://www.toptal.com/developers/keycode shows correct scan codes, so it is not a browser bug or a JavaScript API limitation. SDL uses deprecated EmscriptenKeyboardEvent::keyCode which seems to be filled from JavaScript's event.keyCode which contains wrong value even in JavaScript (if check using the website above). SDL should use a modern attribute EmscriptenKeyboardEvent::code which filled with the correct values on non-QWERTY keyboards (at least it shows correct values on the website).

OS: Windows, Mac OS X
Browser: Google Chrome
Latest stable Emscripten version with builtin SDL2 library

[icculus]

Threw this together real fast from testsprite2.c ...

https://icculus.org/~icculus/emscripten/testsprite-keyboard-logging/

Bring up the console and hit some keys, and it reports this for me pressing the 'q' key with my QWERTY keyboard set to US English:

INFO: SDL EVENT: SDL_KEYDOWN (timestamp=10898 windowid=1 state=pressed repeat=false scancode=20 keycode=113 mod=0)
INFO: SDL EVENT: SDL_TEXTINPUT (timestamp=10899 windowid=1 text='q')
INFO: SDL EVENT: SDL_KEYUP (timestamp=10980 windowid=1 state=released repeat=false scancode=20 keycode=113 mod=0)

...switched the keyboard layout to French AZERTY, and the same key does this...

INFO: SDL EVENT: SDL_KEYDOWN (timestamp=99416 windowid=1 state=pressed repeat=false scancode=4 keycode=97 mod=0)
INFO: SDL EVENT: SDL_TEXTINPUT (timestamp=99417 windowid=1 text='a')
INFO: SDL EVENT: SDL_KEYUP (timestamp=99508 windowid=1 state=released repeat=false scancode=4 keycode=97 mod=0)

So yeah, the keycode should change, but the scancode should not be changing. @KivApple is right, I'm going to try his suggestions.

[icculus]

Gonna track this over in #2098, which has a patch already.