Modifier keys (meta/windows/super, alt, shift, ctrl) can sometimes get stuck

[jtroo]

Testing hyper-modded keys in a layer:

As I was testing this out, kanata entered a borked state, where:

• At rest/in the default layer without any toggles etc:

  • All the keys behave as if in their hyper counterparts
  • eg, a becomes S-C-M-A-a and so on
  • adding modifiers to pressing a, eg ctrl+a still emits S-C-M-A-a etc
  • Except for the hjkl keys that I'd defined as the arrows
  • those emit their original letters, without any modifiers (??)

• Yet holding down capslock:

  • allows me to use the hjkl keys as arrows, and add any modifiers as desired, and it works as configured
  • but the rest of the non hjkl keys still emit their all-modifiers combos (technically correct per config)

• But thus I'm in some kind of unusable hybrid state of the default qwerty I have and the new hyper layer!

• invoking lrld did indeed reload according to my terminal, but it didn't unbork this state

• this weird state in fact occurred as I was trying to write this very comment

• I couldn't terminate kanata in my terminal either, as ctrl-z/c emitted their all-modifiers versions no matter what modifiers I'd added

  • I happened to also being using a quake-mode terminal window without a close button either so I couldn't use a mouse to close it

• I'd encountered this state before with AHK, and the fix was to simply tap each modifier key once to 'unstick' them, but this did not work here

• I thought I was stuck like this until a reboot or something, but at some point, perhaps after a sequence of mashing various modifiers and triggering lrld several times, and it fixed itself

  • Still, it's a potentially dangerous state to be in if I'm in the middle of a presentation, or recording music in realtime or something.

Any clue what might have happened or something to try to prevent or escape from it in the future?

---

Also, more usage questions, apologies if I'm getting annoying:

1. I noticed that with both my AHK solution and with this one that when using the vim-right key (capslock + the letter L), plus Win, instead of (or in addition to) emitting Win + Right (eg for moving the active window to the right), it locks Windows. That is, it fails to override the windows hotkey of Win+L for Lock. Would the interception driver solve this, or running kanata as admin, or something else?

Originally posted by @riotrah in https://github.com/jtroo/kanata/discussions/185#discussioncomment-4142758

[jtroo]

@riotrah I've done some testing on this using configuration with the llhook mechanism.

(defcfg process-unmapped-keys true)

(defsrc 
  7 8 9 0 
  caps
)

(deflayer base 
  _ _ _ _
  (tap-hold-press 200 200 caps (layer-while-held layer))
)

(deflayer layer 
  C-S-A-M-b C-S-A-M-a C-S-A-M-c C-S-A-M-k
  _
)

I haven't been able to create any strange or incorrect behaviour so far. Are there specific key combinations that are triggering the bug?

Additional reproduction info would be great 🙂

[riotrah]

I've changed nothing about my computer usage, yet I haven't actually repro'd it since that first day I was setting it up 🤷.

My computer happened to be a lil sluggish as I was rendering a bunch of audio files at the time. Perhaps there's some mistiming issue or something when under load? Couldn't begin to guess.

[riotrah]

So I perused kmonads repo for tips on running at startup. I couldn't find much relevant info I guess because keyword search is hard in popular projects, but I did see a couple of issues about stuck keys.

I wish I copied the urls but I didn't and couldn't find them again easily. However, it looks like there are a couple of cases that might trigger a stuck key , modifier or otherwise.

1. Having the modifier keys held down while Kanata starts, or perhaps lrlds

   • because I'm addicted to my caps lock hyper key behavior, I might have had AHK running while I was testing out kanata
     • probably not though as that probably would have made testing out my Kanata config nigh impossible
   • still, I might have had the keys physically held down or something

2. Having Kanata emit a modifier before Windows locks or sleeps or something, and then reactivating windows, thereby keeping the press - because no release event was emitted, the keys stayed held down

   • not sure if Kanata is prey to the same issues with the mechanism that monad uses, however, I think the LLhook is the same?

[jtroo]

Just for some context, and for visibility, I'll repeat something I mentioned in a different issue. In my perusing, others have encountered a similar issue without using kanata. I've seen someone say it's happened to them when using only AHK; they weren't a kanata user.

So it seems like the issue is not directly related to kanata; it's something to do with the hook mechanism and/or SendInput.

[riotrah]

I'm not familiar with win32 APIs (though at this point I suppose it wouldn't hurt to learn), so to clarify:

1. "the hook"/llhook refers to this windows keyboard "hook" - which I gather from its mentions in AHK, Kanata, powertoys and kmonad, and from the intense frustration many have with interception which suggests it's the only other real alternative, is the only API with which one can implement really "robust" key remapping on windows

2. I'm not at my PC but SendInput is the AHK flag to utilize the hook as opposed to some other method, correct?

That all makes sense. I suppose I could have just as easily googled that.

And it increasingly appears that in the similar cases seen so far, AHK might be the thing responsible for setting these pressed states as far as the hook is concerned. Then somehow Kanata and AHK start overlapping or conflicting somehow at which point "no one" is able to communicate any subsequent releases to the hook.

I guess what I don't get, is:

1. Why I'm able to unstick keys in AHK by tapping them again, yet the memorable last time I had this issue, tapping didn't unstick them. Perhaps there was some conflict between the two apps?

2. If so, I'm wondering why it hasn't happened since. I've been using both at once to great effect, and it's likely many of the same conditions from when things got messed up reoccurred. Certainly the same config is in place 🤔

Either way, I suppose this bug is resolved for now for me. Thanks for the update!

[jtroo]

Let's leave this ticket open for visibility.

For reference:

• hooks documentation: https://learn.microsoft.com/en-gb/windows/win32/api/winuser/nf-winuser-setwindowshookexa?redirectedfrom=MSDN
• SendInput documentation: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-sendinput