`glfwSetKeyCallback()` : inconsistent behavior on non QWERTY keyboard layouts

[SuperUserNameMan]

This is going to be complicated to explain, so please, be patient with me :

My keyboard is AZERTY layout.

My A key is located at the same location than the Q key of a QWERTY keyboard.
At the hardware level, they share the same scancode, because : same location = same scancode.

Using keyboard scancodes is helpful when you make a video-game that maps "WASD" keys to directions, because the location of these "WASD" keys are always the same whatever is the layout of the user's keyboard. The game can work out of the box without remapping the keyboard.

Here is the issue :

When I use GLFW in C, the callback passed to glfwSetKeyCallback() will receive correct scancodes.
When I use GLFW in Emscripten, the callback passed to glfwSetKeyCallback() will receive INCORRECT scancodes.

This is because library_glfw.js makes use of the outdated KeyboardEvent.keyCode instead of KeyboardEvent.code.

.keyCode is not an hardware scancode, and it breaks compatibility and consistency between GLFW in C and Emscripten.

emscripten/src/library_glfw.js

Lines 410 to 433 in 9bdb310

	onKeydown: (event) => {
	GLFW.onKeyChanged(event.keyCode, 1); // GLFW_PRESS or GLFW_REPEAT
	// This logic comes directly from the sdl implementation. We cannot
	// call preventDefault on all keydown events otherwise onKeyPress will
	// not get called
	if (event.keyCode === 8 /* backspace */ || event.keyCode === 9 /* tab */) {
	event.preventDefault();
	}
	},
	onKeyup: (event) => {
	GLFW.onKeyChanged(event.keyCode, 0); // GLFW_RELEASE
	},
	onBlur: (event) => {
	if (!GLFW.active) return;
	for (var i = 0; i < GLFW.active.domKeys.length; ++i) {
	if (GLFW.active.domKeys[i]) {
	GLFW.onKeyChanged(i, 0); // GLFW_RELEASE
	}
	}
	},

emscripten/src/library_glfw.js

Lines 379 to 382 in 9bdb310

	onKeyChanged: (keyCode, status) => {
	if (!GLFW.active) return;
	var key = GLFW.DOMToGLFWKeyCode(keyCode);

emscripten/src/library_glfw.js

Lines 149 to 161 in 9bdb310

	DOMToGLFWKeyCode: (keycode) => {
	switch (keycode) {
	// these keycodes are only defined for GLFW3, assume they are the same for GLFW2
	case 0x20:return 32; // DOM_VK_SPACE -> GLFW_KEY_SPACE
	case 0xDE:return 39; // DOM_VK_QUOTE -> GLFW_KEY_APOSTROPHE
	case 0xBC:return 44; // DOM_VK_COMMA -> GLFW_KEY_COMMA
	case 0xAD:return 45; // DOM_VK_HYPHEN_MINUS -> GLFW_KEY_MINUS
	case 0xBD:return 45; // DOM_VK_MINUS -> GLFW_KEY_MINUS
	case 0xBE:return 46; // DOM_VK_PERIOD -> GLFW_KEY_PERIOD
	case 0xBF:return 47; // DOM_VK_SLASH -> GLFW_KEY_SLASH
	case 0x30:return 48; // DOM_VK_0 -> GLFW_KEY_0
	case 0x31:return 49; // DOM_VK_1 -> GLFW_KEY_1
	case 0x32:return 50; // DOM_VK_2 -> GLFW_KEY_2

[sbc100]

Sounds like this is a straightforward bug in our GLFW. Do you think there is any risk to simply switching from keyCode to just `code? Would you be interesting in sending a PR to that effect? I imagine to could be hard to test such as change :(

[SuperUserNameMan]

Do you think there is any risk to simply switching from keyCode to just code ?

Alas, keyCode returns an integer, and code returns a string.

https://developer.mozilla.org/en-US/docs/Web/API/UI_Events/Keyboard_event_code_values

Would you be interesting in sending a PR to that effect?

Alas (again), I'm not good enough with the javascript universe, and i'm a total noob with emscripten.
Plus, according to this page, there seems to be some browser and OS variations that I might not be competent to handle correctly.

I imagine to could be hard to test such as change :(

I think that changing the keyboard layout at OS level could help with testing. And if the OS has a virtual keyboard, it might help too.

• glfwSetKeyCallback() should always return QWERTY scancodes whatever is the active layout.
• glfwSetCharCallback() (which seems to work correctly) should always return the char associated with the key depending on the active layout.