Repository navigation
Conversation
The X11 and Wayland backends each carried a separate hand-maintained keysym -> Key table. The X11 table only mapped the NumLock-on numpad keysyms (KP_0..KP_9), so with NumLock off, where the numpad reports KP_Insert/KP_End/KP_Down/... instead, every numpad key fell through to the catch-all arm and was silently dropped. Hoist a single keysym_to_key() into xkb_keysyms.rs covering both the NumLock-on and NumLock-off numpad keysyms, and call it from both backends. X11 picks up the missing entries as a side effect; Wayland behaviour is unchanged. Closes emoon#433
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #433.
Problem
X11 and Wayland each carried their own hand-maintained keysym →
Keytable. The X11 table only covered the NumLock-on numpad keysyms (XK_KP_0..XK_KP_9). With NumLock off, X11 resolves the numpad through the active modifier state and reportsXK_KP_Insert,XK_KP_End,XK_KP_Down, … instead — none of which were in the table, so they fell through to the catch-all arm and were silently dropped. Wayland derivesKeyfrom the level-0 (NumLock-invariant) keysym and already mapped those, so the numpad worked there in both states.Fix
Hoist a single
pub fn keysym_to_key(sym: u32) -> Option<Key>intoxkb_keysyms.rs(which already owns theXKB_KEY_*constants) as the issue suggested, and call it from both backends. The function maps both the NumLock-on (KP_0..KP_9) and NumLock-off (KP_Insert/KP_End/…) numpad keysyms, so X11 picks up the missing entries as a side effect. Removes ~230 lines of duplicated table.Verification
Added a unit test module to
xkb_keysyms.rscovering the NumLock-off X11 case the issue asked for, plus the NumLock-on case and an unmapped-keysym case.RED→GREEN confirmed: reverting the fix to map only the NumLock-on numpad names (the original X11 behaviour) makes
numpad_maps_with_numlock_offfail; the fix makes it pass.Also built both backends in isolation to confirm neither table lost coverage:
Verified on Linux (x86_64), stable Rust. No hardware/display needed —
keysym_to_keyis a pure function over keysym values, which also makes the X11 side unit-testable for the first time.