Bug: passthrough with ahk not releasing shift while numpad lock is on

[danicc097]

Requirements

• I've searched platform-specific issues, issues and discussions to see if this has been reported before.
• My issue is unrelated to multiple key presses, OR it is and I've confirmed it is not key ghosting.

Describe the bug

Using the default configs at https://github.com/jtroo/kanata/tree/main/docs/simulated_passthru_ahk but with a very high timeout, the shift key will randomly become stuck and can only be released by tapping the physical shift key. This also happens in my own config with 150/300 tap/hold timeouts instead of 1000/1500 for multiple modifiers (shift, ctrl...)

Relevant kanata config

As is https://github.com/jtroo/kanata/blob/main/docs/simulated_passthru_ahk/kanata_dll.kbd

To Reproduce

1. Setup passthrough folder https://github.com/jtroo/kanata/tree/main/docs/simulated_passthru_ahk
2. Execute .ahk script, modified with a 999999 timeout. Press F8 twice
3. Use shift home row mod for a short while. Then shift will appear to be pressed in any keyboard tester without pressing the home row mod or the shift key

Expected behavior

Modifer keys should always be released

Kanata version

v1.8.0-prerelease-1

AHK version: 2.1-alpha.14

Debug logs

No response

Operating system

Windows 11 24h2

Additional context

No response

[eugenesvk]

Have you encountered this during regular typing?

I've tried with and empty config (so no home row mods or anything else) and tried to overload LeftShift. I could only do that when I smash a lot of buttons together very fast and release Shift while the keys are still being buffered, and it doesn't seem to be kanata's fault - kanata reliably calls our AutoHotkey function that types via SendInput. It's just with many keys this function simply doesn't execute SendInput every time reliably, so some events are simply lost.

Maybe this is due to the fact that SI has to unhook before sending, this is a known issue with AHK, so not sure what to do. Or maybe this is caused by something else entirely, so even less sure ;)

So I can think of only 2 potential workaround/fixes

• You could try to fix it by replacing a global inputhook on AHK side that filters all input via kanata and thus is susceptible to the buffering issues with only using kanata for a few keys like home f/j

• Another more fundamental one I've though about originally - instead of asking AHK to send key events, kanata should do it itself, but then mimick the masking that AHK does so that those events would be ignored by AHK and avoid an infinite loop

Empty config tested

;;Test config for kanata.dll use by AutoHotkey, nothings is remapped
(defcfg
  process-unmapped-keys	yes	;;|no| enable processing of keys that are not in defsrc
  log-layer-changes    	no 	;;|no| overhead
)

(defsrc     p)
(deflayer ⌂ p)

P.S.
Maybe try to use SendInput('{Blind}{' vk_hex ' up}'), blind mode avoids doing some stuff, so might be less prone to getting struck (though it still gets stuck)?

[danicc097]

Here's what I got after a few days of testing in 3 different windows machines. All using the same windows, kanata and ahk versions mentioned above.

Numlock 100% causes the broken config. I use numlock key presses to keep my work pc on so that's why I found out.
When numlock is active, e.g. shift is broken as mentioned below. With numlock off everything works.

Notes:

With kanata passthrough, numlock key cannot be switched physically. WIth regular kanata.exe its possible

{Blind} made no difference.

The config works fine on its own with kanata.exe and no ahk scripts running on all machines irrespective of numlock state.

With numlock on: the shift key i.e. pressing f+s+j (shift+arrow left) instead sends left, but the shift key will now be stuck upon releasing f. The trace logs in kanata_passthrough.ahk (didn't modify it) are the same for working and failing states. no extra keys sent and no missing keys in the traces.

f+d+j (ctrl+arrow left) seemed to work fine on all machines regardless of numlock

config:

(defcfg
  process-unmapped-keys yes
  windows-altgr add-lctl-release ;; remove the lctl press that comes as a combo with ralt
)

(defsrc
  esc caps a s d
  f
  h j k l grv ;; arrows and mirrored ctrl shift alt layer
  i u o m ;; extra keys on arrow layer
)
(defvar
  tap-time 1000
  hold-time 1500
)

(defalias
  esccaps (tap-hold-release $tap-time $hold-time caps caps)
  capsescp (tap-hold-release $tap-time $hold-time esc esc)
  a (tap-hold-release $tap-time $hold-time a lalt)
  s (tap-hold-release $tap-time $hold-time s lsft)
  d (tap-hold-release $tap-time $hold-time d lctl)
  f (tap-hold-release $tap-time $hold-time f (layer-while-held arrows))

  k (tap-hold-release $tap-time $hold-time k lctl)
  l (tap-hold-release $tap-time $hold-time l lsft)
  grv (tap-hold-release $tap-time $hold-time grv lalt)
)

(deflayer base
  @esccaps
  @capsescp
  @a
  @s
  @d
  @f h j @k @l @grv
  i u o m ;; extra keys on arrow layer
)

(deflayer arrows
_
_
_
_
_
_ home left down right end
  up Backspace enter Delete
)

[eugenesvk]

Nice, very interesting find!

Have you tried with CapsLock on instead of NumLock? It seems to have a similar effect, though for simplicity I'm only testing with the blank config

So maybe AHK's behavior on those Sends is somehow different when a lock is on? Though I don't know the internals of AHK to guess why that is...

The trace logs in kanata_passthrough.ahk (didn't modify it) are the same for working and failing states. no extra keys sent and no missing keys in the traces.

The trace logs set log levels within Kanata, and since kanata behaves the same (it doesn't do key presses, just sends key info to ahk), they are supposed to be the same.
But the logs within the ahk script that show which show how the script reacts to those events (might need to tweak dbg variable) are different for me - during bugs they do show that the function that is supposed to sendinput doesn't do that, pay attention to the log line above SendInput('{' vk_hex ' up}')

With kanata passthrough, numlock key cannot be switched physically

It can, just not with SendInput + numlock key, I guess SendInput does an extra check for the key status or something? For any other key manually sending numlocks key works to switch it

        sleep(2)
        SendInput('{vk90 down}')
        sleep(2)
        SendInput('{vk90 up}')

so does SetNumLockState !GetKeyState("NumLock", "T"), though this one works even with the physical numlock key

[eugenesvk]

With numlock on: the shift key i.e. pressing f+s+j (shift+arrow left) instead sends left, but the shift key will now be stuck upon releasing f.

With your config the shift key does NOT get stuck, although the other behavior is the same - with numlock on I only get left instead of select+left

[eugenesvk]

With kanata passthrough, numlock key cannot be switched physically

it's the same with regular AHK, sendinput doesn't work as a numlock substitute

NumLock::{ ;
  ToolTip "test." ;
  SendInput('{vk90 down}') ; FAILS
}
NumLock Up::{
  SendInput('{vk90 up}') ; 

  ; SetNumLockState !GetKeyState("NumLock", "T") ; SUCCEEDS
  ToolTip
}

[danicc097]

With numlock on: the shift key i.e. pressing f+s+j (shift+arrow left) instead sends left, but the shift key will now be stuck upon releasing f.

With your config the shift key does NOT get stuck, although the other behavior is the same - with numlock on I only get left instead of select+left

Strange, after getting that select+left my shift key is stuck until i manually press the physical shift key. Tested on 3 machines.

Also, capslock and scroll lock key state doesn't break it either (as long as numlock is off)

[danicc097]

With numlock on: the shift key i.e. pressing f+s+j (shift+arrow left) instead sends left, but the shift key will now be stuck upon releasing f.

With your config the shift key does NOT get stuck, although the other behavior is the same - with numlock on I only get left instead of select+left

Strange, after getting that select+left my shift key is stuck until i manually press the physical shift key. Tested on 3 machines.

Also, capslock and scroll lock key state doesn't break it either (as long as numlock is off)

To clarify, shift is stuck while not using the keyboard. The homerow mod layer d+{key} even works as expected and uppercases.

I also found some ahk issues regarding numpad shenanigans in windows but I'm not sure they're related, since the numpad isn't even being remapped here.

https://www.autohotkey.com/docs/v2/KeyList.htm#numpad

the .ahk debug logs at the line you mention are exactly the same messages with numpad lock on/off:

if isSet(vk_hex) {
      (dbg < _d) ? '' : (dbgtxt .= key_name "       ahk←←←: vk=" kvk '¦' vk_hex ' @l' A_SendLevel ' → ' lvl_to ' ' hooks ' ¦' id_thread '¦ ' 
   ....
}

[eugenesvk]

I don't see any ahk shifts events in your log, those would tell you whether shift down/up events are passed by ahk via this log:

...
↓LShift       ahk←←←: vk=160¦vka0 @l0 → 0 hooks#: ✓¦✓ ¦11456¦ cbKanataOut
...
↑LShift       ahk←←←: vk=160¦vka0 @l0 → 0 hooks#: ✓¦✓ ¦11456¦ cbKanataOut
...

(this is using your config, so it's not physical shift, but your home row mod shift, which kanata translates to LShift and ahk sends as LShift and logs before doing so)

Also you might want to fix unicode display otherwise it's harder to track ↓ vs ↑

So in my no-config test when I smash buttons, releasing the physical shift doesn't send ↑LShift ahk←←←: vk=160¦vka0 @l0 → 0 hooks#: ✓¦✓ ¦11456¦ cbKanataOut event since AHK is busy, and that's how I track the bug

Your logs should also show something. Maybe try to use the newer version of the AHK script in this repo and set dbg_dll to hide more messages from kanata leaving only messages from AHK to spot a difference. And comment out/set levels for all other ahk logs, leaving only this log line right before sendinput