You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I updated GLFW to 3.3.5 a linux user reported that his key rebindings weren't working anymore. Caps Lock was being mapped to Ctrl, and this worked in prior versions of GLFW, but has now stopped, and all keys are now what they are.
The GLFWKeyCallback will have
key = actual key
While expected behaviour would be was that the key was remapped through xmodmap.
The text was updated successfully, but these errors were encountered:
I ran into this issue a while back, at some point in the past. If I understand correctly, GLFW now uses Xkb to handle key mappings, and Xmodmap no longer works. Instead I switched to using setxkbmap instead of Xmodmap for my personal setup, since apparently Xmodmap is deprecated now.
This change was introduced in b25ee39 to fix the issue described in #1598, and first released in version 3.3.3. It affects both keys remapped with xmodmap and with XKB.
Previously, some keys (including modifier keys, like control) would be translated to keysyms, taking into account configured mappings. The key identities are now accessed directly, and based on the comment in the current version of x11_init.c, this appears to be the intended behavior. That makes sense for applications where the user wants to bind a specific keyboard key to a particular action, regardless of the usual meaning of that key.
The correct approach is probably to check the modifier bits instead, as those are still being set with the current layout in mind. Unfortunately, there doesn't seem to be a general way to get the modifier state from GLFW.
When I updated GLFW to 3.3.5 a linux user reported that his key rebindings weren't working anymore. Caps Lock was being mapped to Ctrl, and this worked in prior versions of GLFW, but has now stopped, and all keys are now what they are.
The GLFWKeyCallback will have
key = actual key
While expected behaviour would be was that the key was remapped through xmodmap.
The text was updated successfully, but these errors were encountered: