Layer keys sometimes lead to duplicate keypresses

[matklad]

Describe the bug

This is a bit hard to describe, but I've noticed that I sometimes get two/three duplicate keys when using kanata.

Here's a video where I type type, but occasionally get typee or even typeee:

eee.mp4

What happens here is that, right after I type e, I press spc to switch the layers (I want to use my motion layer next). It feels like I get duplicated es if I press spc too fast.

Version

kanata 1.3.0

Relevant kanata configs

(defsrc
        grv  1    2    3    4    5    6    7    8    9     0    -    =    bspc
        tab  q    w    e    r    t    y    u    i    o     p    [    ]    \
        caps a    s    d    f    g    h    j    k    l     ;    '    ret
   lsft 102d z    x    c    v    b    n    m    ,    .     /    rsft
        lctl lmet lalt           spc            ralt rmet  rctl)

(deflayer qwerty
        grv  1    2    3    4    5    6    7    8    9     0    -    =    bspc
        tab  q    w    e    r    t    y    u    i    o     p    [    ]    \
        esc  a    s    d    f    g    h    j    k    l     ;    '    ret
    lsft @w0  @lc  @lm  @la v    b    n    m    @ra  @rm @rc  rsft
        lctl lmet lalt           @sp            ralt rmet  rctl)

(deflayer motion
        grv  1    2    3    4    5    6    7    8    9     0    -    =    bspc
        tab  q    w    e    r    t    y    pgup up   pgdn  p    [    ]    \
        esc  a    s    d    f    g    bspc lft  down rght del   '    ret
    lsft @w0  @lc  @lm  @la v    b    ret  m    home end   /    rsft
        lctl lmet lalt           @sp            ralt rmet  rctl)

(defalias
    sp (tap-hold 200 200 spc (layer-toggle motion))
    lc (tap-hold 200 200 z lctl)
    lm (tap-hold 200 200 x lmet)
    la (tap-hold 200 200 c lalt)
    ra (tap-hold 200 200 , lalt)
    rm (tap-hold 200 200 . rmet)
    rc (tap-hold 200 200 / rctl)
    w0 M-0)

Debug logs

Here's a debug log for typee (I am using workman layout, so the key names are not type):

22:52:22 [DEBUG] (2) kanata::kanata: key press     F
22:52:22 [DEBUG] (2) kanata::oskbd::linux: input ev: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_F), value: 1 }
22:52:22 [DEBUG] (2) kanata::kanata: key press     H
22:52:22 [DEBUG] (2) kanata::oskbd::linux: input ev: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_H), value: 1 }
22:52:22 [DEBUG] (2) kanata::kanata: key release   F
22:52:22 [DEBUG] (2) kanata::oskbd::linux: input ev: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_F), value: 0 }
22:52:22 [DEBUG] (2) kanata::kanata: key press     O
22:52:22 [DEBUG] (2) kanata::oskbd::linux: input ev: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_O), value: 1 }
22:52:22 [DEBUG] (2) kanata::kanata: key release   H
22:52:22 [DEBUG] (2) kanata::oskbd::linux: input ev: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_H), value: 0 }
22:52:22 [DEBUG] (2) kanata::kanata: key press     K
22:52:22 [DEBUG] (2) kanata::oskbd::linux: input ev: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_K), value: 1 }
22:52:22 [DEBUG] (2) kanata::kanata: key release   O
22:52:22 [DEBUG] (2) kanata::oskbd::linux: input ev: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_O), value: 0 }
22:52:22 [INFO] Entered layer:

(deflayer motion
        grv  1    2    3    4    5    6    7    8    9     0    -    =    bspc
        tab  q    w    e    r    t    y    pgup up   pgdn  p    [    ]    \
        esc  a    s    d    f    g    bspc lft  down rght del   '    ret
    lsft @w0  @lc  @lm  @la v    b    ret  m    home end   /    rsft
        lctl lmet lalt           @sp            ralt rmet  rctl)
22:52:22 [DEBUG] (2) kanata::kanata: key release   K
22:52:22 [DEBUG] (2) kanata::oskbd::linux: input ev: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_K), value: 0 }
22:52:22 [DEBUG] (2) kanata::kanata: key outs for active layer-while-held: [KEY_SPACE];
22:52:22 [DEBUG] (2) kanata::kanata: key outs for default layer: [KEY_SPACE];
22:52:22 [DEBUG] (2) kanata::kanata: key outs for active layer-while-held: [KEY_SPACE];
22:52:22 [DEBUG] (2) kanata::kanata: key outs for default layer: [KEY_SPACE];
22:52:22 [DEBUG] (2) kanata::kanata: key outs for active layer-while-held: [KEY_SPACE];
22:52:22 [DEBUG] (2) kanata::kanata: key outs for default layer: [KEY_SPACE];
22:52:22 [DEBUG] (2) kanata::kanata: key outs for active layer-while-held: [KEY_SPACE];
22:52:22 [DEBUG] (2) kanata::kanata: key outs for default layer: [KEY_SPACE];
22:52:23 [INFO] Entered layer:

(deflayer qwerty
        grv  1    2    3    4    5    6    7    8    9     0    -    =    bspc
        tab  q    w    e    r    t    y    u    i    o     p    [    ]    \
        esc  a    s    d    f    g    h    j    k    l     ;    '    ret
    lsft @w0  @lc  @lm  @la v    b    n    m    @ra  @rm @rc  rsft
        lctl lmet lalt           @sp            ralt rmet  rctl)

Now that I've looked at it, here's a better log where I get just eee:

22:54:16 [DEBUG] (2) kanata::kanata: key press     K
22:54:16 [DEBUG] (2) kanata::oskbd::linux: input ev: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_K), value: 1 }
22:54:16 [INFO] Entered layer:

(deflayer motion
        grv  1    2    3    4    5    6    7    8    9     0    -    =    bspc
        tab  q    w    e    r    t    y    pgup up   pgdn  p    [    ]    \
        esc  a    s    d    f    g    bspc lft  down rght del   '    ret
    lsft @w0  @lc  @lm  @la v    b    ret  m    home end   /    rsft
        lctl lmet lalt           @sp            ralt rmet  rctl)
22:54:16 [DEBUG] (2) kanata::kanata: key release   K
22:54:16 [DEBUG] (2) kanata::oskbd::linux: input ev: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_K), value: 0 }
22:54:16 [DEBUG] (2) kanata::kanata: key outs for active layer-while-held: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for default layer: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for active layer-while-held: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for default layer: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for active layer-while-held: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for default layer: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for active layer-while-held: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for default layer: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for active layer-while-held: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for default layer: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for active layer-while-held: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for default layer: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for active layer-while-held: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for default layer: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for active layer-while-held: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for default layer: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for active layer-while-held: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for default layer: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for active layer-while-held: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for default layer: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for active layer-while-held: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for default layer: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for active layer-while-held: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for default layer: [KEY_SPACE];
22:54:16 [INFO] Entered layer:

(deflayer qwerty
        grv  1    2    3    4    5    6    7    8    9     0    -    =    bspc
        tab  q    w    e    r    t    y    u    i    o     p    [    ]    \
        esc  a    s    d    f    g    h    j    k    l     ;    '    ret
    lsft @w0  @lc  @lm  @la v    b    n    m    @ra  @rm @rc  rsft
        lctl lmet lalt           @sp            ralt rmet  rctl)

It seems the sequence of events here is:

1. I depress e
2. I depress spc
3. I release e

So the keypress straddles a layer switch, and that somehow causes triplication of the event.

Operating system

Linux (NixOS), wayland

[matklad]

🤔 interestingly, if I bump my repeat delay in plasma 10x to 2.5 seconds, the effect goes away (my default delay is fairly tight 250ms). Maaaybe the problem exists between the chair and the keyboard and I just keep the key pressed too long? I am not sure -- I am not getting "spurious" repeats outside of layer switching. Still, I guess bumping the repeat delay to 400ms might be a good-enough work-around for me?

[jtroo]

The answer to this is a little more subtle and perhaps interesting than PEBCAK vs. a kanata bug.

On Linux, kanata may choose to send a value: 2 (repeat) event when it receives a value: 2 event from the kernel on the /dev/input device. This repeat event occurs when the kernel decides that a key repeat should occur. Kanata sending such an event would be seen in a line that looks like this from the sample (but with value: 2):

22:54:16 [DEBUG] (2) kanata::oskbd::linux: input ev: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_K), value: 1 }

Doing it this way allows key repeat in a console-only scenario with no desktop environment (DE). I don't see any of these events being sent which means that kanata isn't activating key repeats of its own volition.

From what I've read in the past, DEs may ignore these value: 2 events and have their own repeat timings, purely based on the value: 1 (press) event and the time elapsed until value: 0 (release) happens. This appears to be what's happening here.

The kernel knows that space has been pressed and is being held, so it's sending value: 2 events for space to kanata. This can be inferred in the log messages below, which is kanata checking if it should send a repeat event. Kanata decides not to send a repeat event itself, because the physical space key corresponds to a layer-while-held action in this moment, rather than a "typing space" action.

22:54:16 [DEBUG] (2) kanata::kanata: key outs for default layer: [KEY_SPACE];
22:54:16 [DEBUG] (2) kanata::kanata: key outs for active layer-while-held: [KEY_SPACE];

However, the DE has no way to know that the space key has actually been pressed - it thinks the physical K is the only key being pressed, and so will do key repeats for it, even though space has already been pressed. This is different compared to if the DE knew that space was pressed. This should be able to be seen when holding A and quickly tapping B for example - A no longer repeats. The way you think these key sequences should behave is correct, because that's how it behaves without this interesting interaction between the kernel, kanata, and the DE.

Another different workaround you might be able to do in kanata is to add a multi to space and send a key that behaves like a no-op, maybe f24. Something like (defalias sp (multi f24 (tap-hold ...))).

Or perhaps the DE has a way to configure itself to ignore its builtin repeat mechanism and rely on the input device's value: 2 mechanism. I haven't been able to find a way to get the DE to repeat based on the value: 2 events, and I don't think such a mechanism exists.

[ArijanJ]

(defalias sp (multi f24 (tap-hold ...)))

Oh my god, this has been annoying me for ages, thank you for figuring it out!
I know it doesn't affect many people unless the repeat delay is super low, but maybe we should document it somewhere near the tap-hold family?

[jtroo]

Yea that would be a welcome doc addition 🙂

Please file a PR to update the doc or file an issue for the doc work, thanks!

[mattiasJohnson]

Just coming over from TouchCursor and this was a must-have feature for me. This would affect every user who wants to use space for changing layers (+who has a fast repeat rate). I do not feel I have the knowledge for adding this properly to the docs, would you be able to add this part?

edit: created issue #562

[xDarksome]

Is it possible that the multi hack stopped working? I just recently started using kanata, encountered the issue, found this discussion, applied the hack. And I'm still experiencing the issue, although perceivably less.

[jtroo]

If it did stop working, that would probably be in the desktop environment and not kanata.

I would need more detail about precise desktop/application outputted keysyms corresponding to a physical input sequence, with kanata --debug logs to know more though.

[xDarksome]

Thanks for a quick reply!

OS: NixOS
Window manager: sway (repeat delay 200ms)
Terminal emulator: wezterm
Editor: helix

Scenario:

• press s+d+f in a single stroke
• press space

This sometimes results in the following output

sdfff

Log

2024-02-13T19:14:15.732290208Z [DEBUG] (2) kanata::kanata: process recv ev KeyEvent { code: KEY_S, value: Press }
2024-02-13T19:14:15.732314275Z [DEBUG] (2) kanata::kanata: key press     S
2024-02-13T19:14:15.732317149Z [DEBUG] (2) kanata::oskbd::linux: send to uinput: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_S), value: 1 }
2024-02-13T19:14:15.738099531Z [DEBUG] (2) kanata::kanata: process recv ev KeyEvent { code: KEY_D, value: Press }
2024-02-13T19:14:15.738137074Z [DEBUG] (2) kanata::kanata: key press     D
2024-02-13T19:14:15.738138622Z [DEBUG] (2) kanata::oskbd::linux: send to uinput: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_D), value: 1 }
2024-02-13T19:14:15.75704081Z [DEBUG] (2) kanata::kanata: process recv ev KeyEvent { code: KEY_F, value: Press }
2024-02-13T19:14:15.757073135Z [DEBUG] (2) kanata::kanata: key press     F
2024-02-13T19:14:15.757080464Z [DEBUG] (2) kanata::oskbd::linux: send to uinput: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_F), value: 1 }
2024-02-13T19:14:15.845169214Z [DEBUG] (2) kanata::kanata: process recv ev KeyEvent { code: KEY_SPACE, value: Press }
2024-02-13T19:14:15.845188682Z [DEBUG] (2) kanata::kanata: key press     F24
2024-02-13T19:14:15.845191156Z [DEBUG] (2) kanata::oskbd::linux: send to uinput: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_F24), value: 1 }
2024-02-13T19:14:15.901843588Z [DEBUG] (2) kanata::kanata: process recv ev KeyEvent { code: KEY_S, value: Release }
2024-02-13T19:14:15.918811499Z [DEBUG] (2) kanata::kanata: process recv ev KeyEvent { code: KEY_D, value: Release }
2024-02-13T19:14:15.943345437Z [DEBUG] (2) kanata::kanata: process recv ev KeyEvent { code: KEY_F, value: Release }
2024-02-13T19:14:15.970953419Z [DEBUG] (2) kanata::kanata: process recv ev KeyEvent { code: KEY_SPACE, value: Release }
2024-02-13T19:14:15.97099237Z [DEBUG] (2) kanata::kanata: key press     Space
2024-02-13T19:14:15.970994453Z [DEBUG] (2) kanata::oskbd::linux: send to uinput: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_SPACE), value: 1 }
2024-02-13T19:14:15.972082999Z [DEBUG] (2) kanata::kanata: key release   S
2024-02-13T19:14:15.972115848Z [DEBUG] (2) kanata::oskbd::linux: send to uinput: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_S), value: 0 }
2024-02-13T19:14:15.973215114Z [DEBUG] (2) kanata::kanata: key release   D
2024-02-13T19:14:15.97323148Z [DEBUG] (2) kanata::oskbd::linux: send to uinput: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_D), value: 0 }
2024-02-13T19:14:15.974300012Z [DEBUG] (2) kanata::kanata: key release   F
2024-02-13T19:14:15.974302491Z [DEBUG] (2) kanata::oskbd::linux: send to uinput: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_F), value: 0 }
2024-02-13T19:14:15.975377831Z [DEBUG] (2) kanata::kanata: key release   F24
2024-02-13T19:14:15.975393999Z [DEBUG] (2) kanata::oskbd::linux: send to uinput: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_F24), value: 0 }
2024-02-13T19:14:15.975402302Z [DEBUG] (2) kanata::kanata: key release   Space
2024-02-13T19:14:15.97540347Z [DEBUG] (2) kanata::oskbd::linux: send to uinput: InputEvent { time: SystemTime { tv_sec: 0, tv_nsec: 0 }, kind: Key(KEY_SPACE), value: 0 }

Config: https://github.com/xDarksome/nixos-config/blob/2f402aea858d46afc7f3e92b338fd4b71656b3de/kanata/asus.kbd

[jtroo]

I don't see anything incorrect in the Kanata behaviour according to the debug logs. It's not a keyboard chattering issue either - the events all look as expected. So unfortunately, to my observation at least, it seems like there's something at the desktop or application layer that's behaving poorly.

[xDarksome]

I see, probably wezterm/helix are doing something weird. I'll investigate, thanks!

[tilliwilli]

I just came upon this here, ignoring it at first since it's marked as applying to Linux only and I'm on macOS.

I have exactly the same issue with antedecent keys being repeated that should not be repeated, in my case I stumbled upon it with my homerow mods, making them completely unusable.

I drew up the following simulation, showing that's indeed a katana issue and not a system level thing: https://jtroo.github.io?data=BQEwpgZgzgTgxgAgIYIEYEoBQpJIDYCWSUmCaCwALkgA4C0AFgPZ4gIBMADJx9+XlAiUsWHBDxIAnmBhpiYZAgACGTAB8NmrdrUgAXAGkwkgIKZKegMw99RyQCFzVngFdDxsxYCsfN3ftAA

Why is button A released only after 230ms, and not after 60ms as specified in the input? I don't see any reason why it should be held...
And exactly this is what's happening with homerow mods: E.g. rolling (assuming qwerty here) 'e' (a regular key) into 'f' (a homerow modded key) causes at least a single repetition of 'e' for me, since I also have a very low key repeat delay set.

PS: Even adding the multi trick in the simulation shows that A is not released correctly.

[jtroo]

The event order is by design. Imagine if A was lsft. Releasing lsft before a decision on @b has been made is incorrect. Example link.

[tilliwilli]

Hmm, but, it isn't. It's neither lsft nor any other modifier. It's just a regular key. And even if it was, if I let it go before that other tap-hold key has decided what it's gonna be, then that's how it is and that other key won't be modified. If I want to modify that other key, then I need to hold the modifier long enough. It's that simple, isn't it?

Am I wrong here? What's the reasoning behind holding a key longer than the user physically holds it (if it's not a sticky key or something)? It's very unexpected for me to see that being done. As far as I can tell, my custom keyboard running ZMK has never surprised me in that way with stuff I was not intending to do, and I have very contrived behaviours defined there as well...

[jtroo]

The reasoning is to match the behaviour compared to when Kanata wasn't present. If b was initially pressed while lsft was pressed, why should b get conditionally capitalized based on release order? This can lead to mistyped characters. It is unfortunate that Linux DEs decided to implement key repeat the way they did, but I currently do not have any plan to change the behaviour. I view the inconsistent capitalization to be more negatively impactful because there is no workaround, whereas antecedent key repeat does have workarounds.

I suppose one could implement a configuration to process releases ahead of tap-hold decisions, though I won't be doing so any time soon.

[tilliwilli]

Ok I don't get the reasoning with whatever Linux is doing since I'm using macOS, as mentioned in my initial post. And on macOS without kanata, if I hold a key, and while holding that key I press and release shift repeatedly, the repeated keys get shifted as long as shift is held, and unshifted as soon as I release shift, like "bbbbbbbbBBBBBBBBBbbbbbbbbbBBBBBBBBBbbbbbbbBBBBBBBBBBbbbbbbbbbBBBBBBBBBbbb". Is this different on Linux?
And if it is, then why is the implementation not using OS detection to do whatever is "normal" for each OS?

And as I said, I don't see any working workaround for that issue. That multi f24 thing does not change anything...
The only "fix" that is partly working for me is the simulation of ZMKs require-prior-idle with a "typing layer" that is shortly activated after each keypress, but even that is not working under every circumstance.

[jtroo]

the repeated keys get shifted as long as shift is held, and unshifted as soon as I release shift, like "bbb[...]Bbbb" why is the implementation not using [...]?

1. This has nothing to do with the problem being fixed. You can read the KMonad comparison doc for reference: document:

   Some key sequences with tap-hold keys didn't behave how I want:

   • (press lsft) (press a) (release lsft) (release a) (a is a tap-hold key)
   • The above outputs a in kmonad, but I want it to output A

2. This is open source, and I don't personally own any macOS devices, so please do contribute a fix specific to macOS if you have one in mind. The macOS support has been kindly implemented by the community. I have no way to find out why the f24 workaround, which works in Linux, and which isn't needed at all in Windows, does not work for macOS.