Non-printable keys are reported as UNKNOWN if the application is run when not the default keyboard layout is selected.

[hikarideai]

OS: Arch Linux running 5.5.7-zen1-1-zen kernel with i3wm
Commit: from b3eb6dd and onwards

I use the Dvorak keyboard layout for the most part, but the default one is the QWERTY one. (This is very handy. E.g. to switch between windows in i3 I would press MOD+J or MOD+; on QWERTY, and MOD+H or MOD+S on Dvorak -- i.e., I need to press the physical keys that correspond to QWERTY layout no matter the current keyboard layout). When running my application (with Dvorak selected) I've found out that none of the non-printable keys were being reported. I remembered that it worked in GLFW 3.3. I've deduced that the issue arose after #1462 got solved.

It is possible to reproduce it with the current master branch.

The output of events with QWERTY selected:

00000005 to 1 at 2.334: Key 0x0046 Scancode 0x0029 (F) (f) (with no mods) was pressed
00000006 to 1 at 2.334: Character 0x00000066 (f) input
00000007 to 1 at 2.497: Key 0x0046 Scancode 0x0029 (F) (f) (with no mods) was released
00000008 to 1 at 3.396: Key 0x0101 Scancode 0x0024 (ENTER) (with no mods) was pressed
00000009 to 1 at 3.531: Key 0x0101 Scancode 0x0024 (ENTER) (with no mods) was released
0000000a to 1 at 4.152: Key 0x0100 Scancode 0x0009 (ESCAPE) (with no mods) was pressed
0000000b to 1 at 4.312: Key 0x0100 Scancode 0x0009 (ESCAPE) (with no mods) was released
0000000c to 1 at 5.059: Key 0x0106 Scancode 0x0072 (RIGHT) (with no mods) was pressed
0000000d to 1 at 5.213: Key 0x0106 Scancode 0x0072 (RIGHT) (with no mods) was released

And with Dvorak selected

00000005 to 1 at 2.775: Key 0x0046 Scancode 0x0029 (F) (u) (with no mods) was pressed
00000006 to 1 at 2.775: Character 0x00000075 (u) input
00000007 to 1 at 2.904: Key 0x0046 Scancode 0x0029 (F) (u) (with no mods) was released
00000008 to 1 at 4.657: Key 0xffffffff Scancode 0x0024 (UNKNOWN) (with no mods) was pressed
00000009 to 1 at 4.707: Key 0xffffffff Scancode 0x0024 (UNKNOWN) (with no mods) was released
0000000a to 1 at 5.537: Key 0xffffffff Scancode 0x0009 (UNKNOWN) (with no mods) was pressed
0000000b to 1 at 5.741: Key 0xffffffff Scancode 0x0009 (UNKNOWN) (with no mods) was released
0000000c to 1 at 6.202: Key 0xffffffff Scancode 0x0072 (UNKNOWN) (with no mods) was pressed
0000000d to 1 at 6.343: Key 0xffffffff Scancode 0x0072 (UNKNOWN) (with no mods) was released

I have the following keyboard configuration:

/etc/X11/xorg.conf.d/00-keyboard.conf
-------------------------------------
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "us,us,ru"
        Option "XkbModel" "pc104"
        Option "XkbVariant" ",dvorak,typewriter"
        Option "XkbOptions" "grp:alt_shift_toggle"
EndSection

I've tried to swap Dvorak and QWERTY in the configuration and try again. The events reported correctly the non-printable keys for the Dvorak now and incorrectly for QWERTY.

I assume that only the first layout (zeroth group) provides mappings for non-printable keys.

I think the fix is simple, but I may not know all the consequences it may lead to.

In lines:

glfw/src/x11_init.c

Line 56 in 44b5d06

keySym = XkbKeycodeToKeysym(_glfw.x11.display, scancode, _glfw.x11.xkb.group, 1);

and

glfw/src/x11_init.c

Line 78 in 44b5d06

keySym = XkbKeycodeToKeysym(_glfw.x11.display, scancode, _glfw.x11.xkb.group, 0);

If the _glfw.x11.xkb.group will be replaced back to 0, the issue gets solved: the printable keys for different layouts are reported differently and the non-printable keys are reported correctly for all (or in my case, US-QWERTY, US-Dvorak, and RU-Typewriter) layouts.

Is this fix OK?

[ZenulAbidin]

A pull request of mine related to this issue is pending. #1598

When I was inspecting this problem I noted that the fourth parameter roughly corresponds to the keyboard layout number, so I think (emphasis on think, I'm probably wrong) changing it to 0 might break input from the second keyboard layout. Since input in Linux/X.org is always handed by evdev, an event input interface in the kernel, it is safe to dispense with translateKeyCode() entirely and compare the GLFW scancode name with the evdev event code name (SPCE, ESC, etc.)

[elmindreda]

This issue should be fixed now in master thanks to the PR by @ZenulAbidin.