hyprwm / Hyprland

Hyprland is an independent, highly customizable, dynamic tiling Wayland compositor that doesn't sacrifice on its looks.
https://hyprland.org
BSD 3-Clause "New" or "Revised" License
21.49k stars 899 forks source link

Can't shift some keys when using non-us keyboard layout #1043

Open felipeagc opened 1 year ago

felipeagc commented 1 year ago

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: image

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

vaxerski commented 1 year ago

I am unsure whether this is handled by Hyprland. Afaik, xkb should deal with this.

felipeagc commented 1 year ago

That's strange, because it works fine on sway

MahouShoujoMivutilde commented 1 year ago

@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 commented 1 year ago

@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
MahouShoujoMivutilde commented 1 year ago

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.

vaxerski commented 1 year ago

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

MahouShoujoMivutilde commented 1 year ago

Thats why you should switch layouts per-device

Very nice, thank you.

jakubkaczor commented 1 year ago

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.

jakubkaczor commented 1 year ago

@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.

vaxerski commented 1 year ago

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.

jakubkaczor commented 1 year ago

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.

vaxerski commented 1 year ago

but it can't be this one since it's long fixed in wlr...?

jakubkaczor commented 1 year ago

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?

vaxerski commented 1 year ago

in hyprland mods are shared between all keyboards regardless of the keymap. Perhaps they're not reported correctly to xkb or something.

jakubkaczor commented 1 year ago

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.

vaxerski commented 1 year ago

I do not. Again, this would align with my theory of not propagating the changes down in the stack

jakubkaczor commented 1 year ago

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.

Ghosthree3 commented 1 year ago

@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.

jakubkaczor commented 1 year ago

@Ghosthree3, no, unfortunately I have not found any other workaround, but if you do, please share. 😉

Kagukara commented 6 months ago

I think the issue I made here: https://github.com/hyprwm/Hyprland/issues/4870 is relate/the same as this issue?

rbran commented 5 months ago

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.

rbran commented 5 months ago

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.

Sectimus commented 4 weeks ago

So is this ever actually going to be fixed or do I just have to buy a new keyboard? I can't disable nkey rollover using a CM storm quickfire TK.

Tried both fn+esc and fn+esc+6 (as per the manual) NADA. I can't even use caps lock...

This is an issue that exists nowhere except Hyperland

jakubkaczor commented 4 weeks ago

So is this ever actually going to be fixed or do I just have to buy a new keyboard? I can't disable nkey rollover using a CM storm quickfire TK.

Replacing hardware because of bugs in software? This opposes the idea that software is for changing the behavior of machines more easily and cheaply, avoiding replacing parts. I suggest changing the compositor.

Tried both fn+esc and fn+esc+6 (as per the manual) NADA. I can't even use caps lock...

The key combination I used for turning N-key rollover off was different from the one in the manual and the one in the suggestion I mentioned before. It was Fn + n + Ins[^1]. Try it out.

[^1]: On my keyboard, Ins key is the one with the 6-key rollover pictogram.

rbran commented 3 weeks ago

Replacing hardware because of bugs in software? This opposes the idea that software is for changing the behavior of machines more easily and cheaply, avoiding replacing parts.

Unfortunately this is not true in a lot of cases today, if your time debugging this issue is worth more money then buying a new keyboard. Then it makes sense to just replace the keyboard.

Of course overall it's better to fix the bug, because it will save a lot of people a lot of time/money. But that's overall, for you individually it may not.