Map function keys independently of key group

[ZenulAbidin]

XkbKeycodeToKeysym in function translateKeyCode in x11_init.c is returning keySym value of -1 when called with the key's scancode. This causes all function and numpad keys to be mapped to GLFW_KEY_UNKNOWN.

Printable keys register correctly because they are mapped explicitly, so I mapped the other keys like that too. There is no reason to use translateKeyCode now.

[ZenulAbidin]

Also, this bug is not present in the latest release.

[elmindreda]

Also, this bug is not present in the latest release.

Do you mean that this bug is present in master but not in 3.3?

[ZenulAbidin]

After running git bisect, I have discovered that this regression was introduced in commit b3eb6dd. The problem is triggered here:

glfw/src/x11_init.c

Lines 670 to 676 in fe57e3c

	_glfw.x11.xkb.group = 0;
	XkbStateRec state;
	if (XkbGetState(_glfw.x11.display, XkbUseCoreKbd, &state) == Success)
	{
	XkbSelectEventDetails(_glfw.x11.display, XkbUseCoreKbd, XkbStateNotify, XkbAllStateComponentsMask, XkbGroupStateMask);
	_glfw.x11.xkb.group = (unsigned int)state.group;
	}

This is related to issue #1462, because I have an English QWERTY keyboard layout and also an Arabic QWERTY layout on my system (this may be why you couldn't reproduce it). The issue is the function keys are only on group 0. My Arabic layout is group 0 while my English layout is group 1. So the function keys only work if I start the program in Arabic layout. If I then switch to English layout while the program is running, it still works, but it's very inconvenient.

This bug is reproducible in master as well as in GLFW 3.3.1.

Over here:

glfw/src/x11_init.c

Lines 256 to 262 in fe57e3c

	// Map the key name to a GLFW key code. Note: We only map printable
	// keys here, and we use the US keyboard layout. The rest of the
	// keys (function keys) are mapped using traditional KeySym
	// translations.
	if (strcmp(name, "TLDE") == 0) key = GLFW_KEY_GRAVE_ACCENT;
	else if (strcmp(name, "AE01") == 0) key = GLFW_KEY_1;
	else if (strcmp(name, "AE02") == 0) key = GLFW_KEY_2;

Since it's assigning ASCII keys here and they return the native character in the current keyboard layout, it would be simpler to assign the function keys there too. The function key names I added in my PR were taken from the evdev key-codes list and I tested all of them.

[elmindreda]

Successfully reproduced on Cygwin/X running MATE with the default Arabic layout.

[elmindreda]

This is a good PR but I cannot merge the removal of the non-XKB code as-is because that path can still be chosen if the XKB extension is unavailable, which would leave all keys unknown. We should either keep the whole fallback path or go all-in and require XKB at init.

The x11-xkb-key-names branch is my proposal for the alternative of keeping the fallback path. I also added checking XKB key aliases, which should help some with non-PC and/or non-evdev platforms, though more work is likely needed for obscure platforms.

Do these changes seem reasonable?

[ZenulAbidin]

@elmindreda

This is a good PR but I cannot merge the removal of the non-XKB code as-is because that path can still be chosen if the XKB extension is unavailable, which would leave all keys unknown.

Good point. We should keep the code that GLFW falls back to if XKB isn't available.

I believe the changes in the x11-xkb-key-names branch are acceptable.

[elmindreda]

This has been merged as a41a58a. Thank you for the fix and your patience through all the delays.

[combolek]

b25ee39 is an important bug fix. May I ask that it be released in 3.3.3 so that Linux distributions pick it up?
Thanks