Hyprland
Hyprland copied to clipboard
hyprwm
Can't shift some keys when using non-us keyboard layout
For some reason I can't shift a lot of the keys on the 'br' keyboard layout, like ',', '.', ';', '/' or any other accent or special character for example. This is the keyboard layout for reference:
If someone could give some pointers on where this is handled in the code I could debug it and submit a PR. Thanks in advance!
EDIT: this is on 0.18.0
I am unsure whether this is handled by Hyprland. Afaik, xkb should deal with this.
@felipeagc how are you configuring your layout?
I've tried
input {
# notice that `us` is first, this matters for hotkeys, at least when using non-latin layouts
kb_layout = us,br
kb_options = caps:escape,grp:alt_shift_toggle
}
and it works fine for me, àĉĉèǹtś.
@felipeagc how are you configuring your layout?
I've tried
input { # notice that `us` is first, this matters for hotkeys, at least when using non-latin layouts kb_layout = us,br kb_options = caps:escape,grp:alt_shift_toggle }and it works fine for me,
àĉĉèǹtś.
Hmmm this still didn't work, it just changed the keyboard layout to the US one, and shift still didn't work. What did work was switching to another keyboard (also with the br layout), which is really weird.
This is the output of hyprland devices:
mice:
Mouse at 82e64140:
CM Storm Quickfire TKL Nkeys Consumer Control
default speed: 0.000000
Mouse at 82da35a0:
Logitech MX518 Gaming Mouse
default speed: 0.000000
Mouse at 82c96470:
Logitech MX518 Gaming Mouse Keyboard
default speed: 0.000000
Keyboards:
Keyboard at 82ca2b80:
Power Button
rules: r "", m "", l "br", v "", o ""
active keymap: Portuguese (Brazil)
main: no
Keyboard at 82c4f0a0:
Video Bus
rules: r "", m "", l "br", v "", o ""
active keymap: Portuguese (Brazil)
main: no
Keyboard at 82c9cc90:
Video Bus
rules: r "", m "", l "br", v "", o ""
active keymap: Portuguese (Brazil)
main: no
Keyboard at 82c70b40:
Power Button
rules: r "", m "", l "br", v "", o ""
active keymap: Portuguese (Brazil)
main: no
Keyboard at 82c65db0:
Burr-Brown from TI USB Audio CODEC
rules: r "", m "", l "br", v "", o ""
active keymap: Portuguese (Brazil)
main: no
Keyboard at 82c595d0:
CM Storm Quickfire TKL Nkeys
rules: r "", m "", l "br", v "", o ""
active keymap: Portuguese (Brazil)
main: no
Keyboard at 82ba2940:
CM Storm Quickfire TKL Nkeys Consumer Control
rules: r "", m "", l "br", v "", o ""
active keymap: Portuguese (Brazil)
main: no
Keyboard at 82e965e0:
CM Storm Quickfire TKL Nkeys System Control
rules: r "", m "", l "br", v "", o ""
active keymap: Portuguese (Brazil)
main: no
Keyboard at 82eae700:
CM Storm Quickfire TKL Nkeys Keyboard
rules: r "", m "", l "br", v "", o ""
active keymap: Portuguese (Brazil)
main: no
Keyboard at 82f16740:
Logitech MX518 Gaming Mouse Keyboard
rules: r "", m "", l "br", v "", o ""
active keymap: Portuguese (Brazil)
main: no
Keyboard at 82f54560:
USB Live camera: USB Live camer
rules: r "", m "", l "br", v "", o ""
active keymap: Portuguese (Brazil)
main: no
Keyboard at 8319df60:
Dell KB216 Wired Keyboard Consumer Control
rules: r "", m "", l "br", v "", o ""
active keymap: Portuguese (Brazil)
main: no
Keyboard at 8318f000:
Dell KB216 Wired Keyboard System Control
rules: r "", m "", l "br", v "", o ""
active keymap: Portuguese (Brazil)
main: no
Keyboard at 832df9a0:
Dell KB216 Wired Keyboard
rules: r "", m "", l "br", v "", o ""
active keymap: Portuguese (Brazil)
main: yes
Tablets:
Touch:
Switches:
The keyboard that's working fine is the Dell one, while shift doesn't work on the CM Storm. Both have the physical brazilian keyboard layout.
On sway I configured the CM Storm's layout like this and it worked ok:
input "9494:20:CM_Storm_Quickfire_TKL_Nkeys_Consumer_Control" xkb_layout br
input "9494:20:CM_Storm_Quickfire_TKL_Nkeys_System_Control" xkb_layout br
input "9494:20:CM_Storm_Quickfire_TKL_Nkeys_Keyboard" xkb_layout br
input "9494:20:CM_Storm_Quickfire_TKL_Nkeys" xkb_layout br
it just changed the keyboard layout to the US one
Yeah, two layouts, when you want to switch between them - press alt+shift.
and shift still didn't work.
At this point I would be tempted to ask "does the key actually work?", but since you said it works in sway, IDK.
Hm, so you use br as a single layout, that's the only difference I see.
my devices
mice:
Mouse at cd52eb50:
Razer Razer DeathAdder
default speed: 0.000000
Mouse at cd4dc4a0:
Logitech USB Keyboard Consumer Control
default speed: 0.000000
Keyboards:
Keyboard at cd411010:
Power Button
rules: r "", m "", l "br", v "", o "caps:escape,grp:toggle"
active keymap: Portuguese (Brazil)
main: no
Keyboard at cd4d0710:
Power Button
rules: r "", m "", l "br", v "", o "caps:escape,grp:toggle"
active keymap: Portuguese (Brazil)
main: no
Keyboard at cd4d8550:
Logitech USB Keyboard
rules: r "", m "", l "br", v "", o "caps:escape,grp:toggle"
active keymap: Portuguese (Brazil)
main: no
Keyboard at cd5a9810:
Logitech USB Keyboard Consumer Control
rules: r "", m "", l "br", v "", o "caps:escape,grp:toggle"
active keymap: Portuguese (Brazil)
main: no
Keyboard at cd5f1100:
Logitech USB Keyboard System Control
rules: r "", m "", l "br", v "", o "caps:escape,grp:toggle"
active keymap: Portuguese (Brazil)
main: no
Keyboard at cd630cf0:
Eee PC WMI hotkeys
rules: r "", m "", l "br", v "", o "caps:escape,grp:toggle"
active keymap: Portuguese (Brazil)
main: yes
Tablets:
Touch:
Switches
But even with the single layout it still works for me !@#$%<>:Çãñâ
Weird.
I know about quirk with hyprland's own bindings when first layout is not us (as an extreme example - ru, when every alphabetic key is non latin), and if you define your bindings as in us, it wont work (even if us is present in kb_layout). (That can be worked around with keycodes, BTW).
I thought it might be related, but I am out of ideas, sorry.
On sway I configured the CM Storm's layout like this and it worked ok: input "9494:20:CM_Storm_Quickfire_TKL_Nkeys_Consumer_Control" xkb_layout br input "9494:20:CM_Storm_Quickfire_TKL_Nkeys_System_Control" xkb_layout br input "9494:20:CM_Storm_Quickfire_TKL_Nkeys_Keyboard" xkb_layout br input "9494:20:CM_Storm_Quickfire_TKL_Nkeys" xkb_layout br
device:CM Storm Quickfire TKL Nkeys Consumer Control {
kb_layout=br
}
??????????? https://wiki.hyprland.org/Configuring/Keywords/#per-device-input-configs
I know about quirk with hyprland's own bindings when first layout is not us (as an extreme example - ru, when every alphabetic key is non latin), and if you define your bindings as in us, it wont work (even if us is present in kb_layout). (That can be worked around with keycodes, BTW).
Thats why you should switch layouts per-device
Thats why you should switch layouts per-device
Very nice, thank you.
I'm also experiencing the issue, but without any additional input configuration, i.e. with defaults. The built-in laptop keyboard works as expected, but the attached one doesn't. I have a standard US layout keyboards. Shortcuts such as Shift + ; for colon character don't work. One more common thing with the OP is that it is also from CM Storm. But it has worked with Sway on Wayland and with Dwm, AwesomeWM and Qtile on X11. The command hyprctl devices returns the following keyboard section.
Keyboards:
Keyboard at 55b19b383210:
video-bus
rules: r "", m "", l "us", v "", o ""
active keymap: English (US)
main: no
Keyboard at 55b19b392c40:
power-button
rules: r "", m "", l "us", v "", o ""
active keymap: English (US)
main: no
Keyboard at 55b19b2ebb70:
cm-storm-quickfire-pro-ultimate-n-key
rules: r "", m "", l "us", v "", o ""
active keymap: English (US)
main: no
Keyboard at 55b19b4ce790:
cm-storm-quickfire-pro-ultimate-n-key-consumer-control
rules: r "", m "", l "us", v "", o ""
active keymap: English (US)
main: no
Keyboard at 55b19b50c080:
cm-storm-quickfire-pro-ultimate-n-key-system-control
rules: r "", m "", l "us", v "", o ""
active keymap: English (US)
main: no
Keyboard at 55b19b546d40:
cm-storm-quickfire-pro-ultimate-n-key-keyboard
rules: r "", m "", l "us", v "", o ""
active keymap: English (US)
main: no
Keyboard at 55b19b581060:
steelseries-rival-gaming-mouse-1
rules: r "", m "", l "us", v "", o ""
active keymap: English (US)
main: no
Keyboard at 55b19b5ba5c0:
steelseries-rival-gaming-mouse-1
rules: r "", m "", l "us", v "", o ""
active keymap: English (US)
main: no
Keyboard at 55b19b5f4680:
at-translated-set-2-keyboard
rules: r "", m "", l "us", v "", o ""
active keymap: English (US)
main: no
Keyboard at 55b19b62dc00:
hp-wmi-hotkeys
rules: r "", m "", l "us", v "", o ""
active keymap: English (US)
main: yes
I am on Arch's hyperland 0.25.0-1.
I piped the output of Hyprland to a log file and there was nothing unusual or related to keyboard input.
Also, there is one quirk. Pressing a shift key turns on num lock, and pressing some not working key, for example mentioned ;, turns it off. Then, pressing some working key, for example j, turns the num lock back on. After pressing Alt + Shift caps lock and num lock toggle alternating in the same situations.
@vaxerski there used to be the same issue in sway.
Errata. The actual respective sway issue is at https://github.com/swaywm/sway/issues/4251, but was regarded as a duplicate of the aforementioned.
firstly, no need to ping me, I am not blind.
Secondly, that's wlroots, not sway. Furthermore, the linked issue is not present in hl and is unrelated to this.
With regard to pinging, I do it when I speak to someone. Is it inappropriate?
When it comes to the issue—right. This isn't strictly a Sway issue. I found it out coming from this one, which was regarded as a duplicate and is the respective issue I firstly meant.
I thought it was fixed by 2 pull requests introducing keyboard groups and sharing modifiers within them. One adding keyboard groups to wlroots, and the other adding support for it in the compositor—Sway. So, as you are saying this is unrelated, I assume this feature is already supported by Hyperland, correct?
in hyprland mods are shared between all keyboards regardless of the keymap. Perhaps they're not reported correctly to xkb or something.
That's weird. If it was a case, with caps lock off, I should be able to press shift on one keyboard, the letter on the other and in the result I should get an upper case letter. Correct? It doesn't happen. Neither with other modifiers, such as Alt or Ctrl. Does it work the other way with your setup? Unless you don't have multiple keyboards at hand.
I do not. Again, this would align with my theory of not propagating the changes down in the stack
Hmm, ok. Reading the previously mentioned issues, I have found a suggestion to turn off the N-key rollover feature. It works also in this case, so it may serve as a temporary quasi-solution.
@jakubkaczor did you ever find a workaround to this that doesn't involve disabling N-key rollover?
I've just run into this myself, standard US keyboard, acts as two devices, can capitalize letters but not symbols like / into ?, and also experience the num lock/caps lock behavior you mentioned where it reflects the state of the most recently used keyboard device (one of them has num lock on, the other off). Not an issue on Sway or any other window manager/desktop environment I've experimented with in the past.
@Ghosthree3, no, unfortunately I have not found any other workaround, but if you do, please share. 😉
I think the issue I made here: https://github.com/hyprwm/Hyprland/issues/4870 is relate/the same as this issue?
I had the same problem on a similar keyboard model (CM Storm Quickfire TK Nkeys), surprisingly the problem don't happen with other USB keyboards, such as 1a2c:0c23 China Resource Semico Co., Ltd USB Keyboard.
So I assume it's an issue in how hyprland interpret the input from this keyboard model.
Here the difference on wev between the CM and Generic Keyboard using only kb_layout = br:
Press Shift, Press :, Release :, Release Shift:
CM
[14: wl_keyboard] modifiers: serial: 0; group: 0
depressed: 00000000
latched: 00000000
locked: 00000000
[14: wl_keyboard] key: serial: 2339; time: 1491228; key: 50; state: 1 (pressed)
sym: Shift_L (65505), utf8: ''
[14: wl_keyboard] modifiers: serial: 0; group: 0
depressed: 00000001: Shift
latched: 00000000
locked: 00000000
[14: wl_keyboard] keymap: format: 1 (xkb v1), size: 66549
[14: wl_keyboard] repeat_info: rate: 25 keys/sec; delay: 600 ms
[14: wl_keyboard] modifiers: serial: 0; group: 2
depressed: 00000000
latched: 00000000
locked: 00000002: Lock
[14: wl_keyboard] key: serial: 2342; time: 1491947; key: 61; state: 1 (pressed)
sym: semicolon (59), utf8: ';'
[14: wl_keyboard] key: serial: 2343; time: 1492127; key: 61; state: 0 (released)
sym: semicolon (59), utf8: ''
[14: wl_keyboard] keymap: format: 1 (xkb v1), size: 66549
[14: wl_keyboard] repeat_info: rate: 25 keys/sec; delay: 600 ms
[14: wl_keyboard] modifiers: serial: 0; group: 0
depressed: 00000001: Shift
latched: 00000000
locked: 00000000
[14: wl_keyboard] key: serial: 2345; time: 1492231; key: 50; state: 0 (released)
sym: Shift_L (65505), utf8: ''
[14: wl_keyboard] modifiers: serial: 0; group: 0
depressed: 00000000
latched: 00000000
locked: 00000000
Generic
[14: wl_keyboard] key: serial: 2424; time: 1515863; key: 50; state: 1 (pressed)
sym: Shift_L (65505), utf8: ''
[14: wl_keyboard] modifiers: serial: 0; group: 0
depressed: 00000001: Shift
latched: 00000000
locked: 00000000
[14: wl_keyboard] key: serial: 2426; time: 1516439; key: 61; state: 1 (pressed)
sym: colon (58), utf8: ':'
[14: wl_keyboard] key: serial: 2427; time: 1516559; key: 61; state: 0 (released)
sym: colon (58), utf8: ''
[14: wl_keyboard] key: serial: 2428; time: 1517055; key: 50; state: 0 (released)
sym: Shift_L (65505), utf8: ''
[14: wl_keyboard] modifiers: serial: 0; group: 0
depressed: 00000000
latched: 00000000
locked: 00000000
Note that difference only happen on Hyprland, on Sway both behave like the generic keyboard.