Closed picuber closed 1 year ago
Oh geez, that output is a mess. Thank you for reporting! I'm curious whenever v1.2.0 produces the correct output?
(sry for the late reply, I couldn't get to my mashine for a bit)
I've tried it out with v1.2.0, and it seems to work. It's still garbled, but it's consistent with dvorak <-> querty (which I assume is the intented functionality)
However, when I tried it with Hyperspeedcube (which is where I originally encountered this bug. If I should open a separate issue over there, do tell me), while with v1.3.0 it seems to do the right things but showing me the wrong lables, with v1.2.0 it shows me the right things (according to the selected keyboard layout on startup) it "presses" (according to the keybinds reference showing them) the opposite garbled key.
E.g.: With v1.3.0: I press U (Dvorak = F Querty), it shows it in the correct place, does the right thing (select R face with Default Keybinds), but displays L. With v1.2.0: I press U (Dvorak = F Querty), it shows it in the place of L (Dvorak = P Querty), and also does the thing that is at that position ("yx", rotate in z axis), but correctly displays U.
Thank you so much for investigating further! There's a few things going on here:
There are two solutions I can think of:
I don't have a Linux install to test this on nor the time to devote to it, but if you want to open a PR doing either of those I would be happy to merge it and include it in the next release of HSC. If not, that's totally understandable.
OS: Arch Linux x86_64 Kernel: 6.0.5-arch1-1 locale: en_US.UTF-8 Keyboard layout: UK Dvorak (setxkbmap gb dvorak caps:escape ) X.Org version: 21.1.4
It seems to produce the wrong mapping on my system. I've also tried it with other keyboard layouts, and setting the X11 Layout with localectl, but it still generates a (albeit a different) wrong mapping.
Output of
localectl status
:Output of
cargo run --example all_keys
: