Some wrong keybinds are showing in Keybinds Reference window
DaraJKong opened this issue · 8 comments
Here I am pressing on Ctrl_Left and this weird artifact shows up:
Expected behavior:
Since no Ctrl + K keybind exists, the K key on the keyboard overlay should be blank.
I'm using Linux x86_64, in case anyone asks...
All of those keybinds are wrong -- BLD should be on B, undo should be on Z, exit should be on Q, ... very strange! I'm curious whether you're using X or Wayland; previously @picuber changed the mapping on Linux to fix key-names#5 on X, but I wonder whether Wayland uses a different mapping. I don't have a Linux machine to test this on, but if you're able to find a way to fix this on Wayland then I can try writing code to select between them depending on whether the system is using Wayland or X.
I forgot to ask: I'm assuming this is on the desktop version rather than web?
Yes, this is on desktop and I'm using X11.
Nevermind, I just read on the issue key-names#5, and I understand what you meant by different mapping... I'll try.
I don't think it's related to key-names. I ran the all_keys examples with key-names v1.5.1, and the output was flawless.
Running localectl status gives:
System Locale: LANG=en_CA.UTF-8
LANGUAGE=en_CA:en
VC Keymap: n/a
X11 Layout: ca
X11 Model: pc105However, Hyperspeedcube displays the keys in wrong places. But the keybinds work as expected (Ctrl + Z does undo).
Not sure what's going on... To be honest, I'm not very experienced with keyboard layouts/mapping and how they work.
If key-names gives me the right output, isn't everything else supposed to work? I don't understand...
Sorry it took so long to reply! I think I've got a solution, so I made a branch on key-names. If you're able to, try adding replacing this line in Hyperspeedcube's Cargo.toml:
key-names = { git = "https://github.com/HactarCE/key-names", tag = "v1.5.1", features = ["winit"] }
with this:
key-names = { git = "https://github.com/HactarCE/key-names", branch = "fix-hsc-31", features = ["winit"] }
and let me know if that fixes it.
The problem is in this function right here, which converts from KeyMappingCode (a platform-agnostic enum representing a physical key on the keyboard) to scancode (an OS-specific number representing a physical key on the keyboard). It's querying the XKB map, but using the evdev code to do it.
The original reason to use evdev codes didn't include this; I just got overzealous with find/replace.
No problem at all! I didn't have the time to look into it myself.
It works wonderfully, nice job!
Awesome! I'll roll that into the next update (which may be 2.0)