Bug: Kanata messes up keyboard from time to time (Windows 10 or 11)

rpnfan commented 3 weeks ago

Requirements

[X] I've searched platform-specific issues, issues and discussions to see if this has been reported before.

Describe the bug

From time to time my keyboard input gets messed up. It seems to either having a hanging Ctrl-key then or some other weird output which I have not found exactly what keystrokes it is sending, when I press keys which should produce characters, but seem to output spaces or tabs.

I had similar problems over all the years I was using Autohotkey. It seems how those programs catch the keyboard input can mess up the keyboard chain in some way.

Fix is to restart Kanata (reload config is sufficient) and wait a few seconds. Killing Kanata does not fix the problem! I need to reload a config, which then fixes the problem.

I had times when I also had other keyboard programs running, like Espanso, but also when Kanata is running alone I get the problems.

Relevant kanata config

No response

To Reproduce

kanata_gui running under Windows (non-admin or admin does not seem to make a difference)
pressing keys rapidly seems sometimes to cause the problem
or waking up from hibernation seems also to be a problem

Expected behavior

no weird keyboard behavior introduced by Kanata ;-)

Kanata version

1.71 pre-version

Debug logs

No response

Operating system

Win 11

Additional context

No response

jtroo commented 3 weeks ago

Unfortunately this bug isn't easily actionable without consistent and precise steps.

I have noticed weirdness, mostly with administrator applications. It seems presses or releases are missed and then the Kanata and/or application and/or OS keystate gets messed up. Doesn't seem easy to fix though.

jtroo commented 3 weeks ago

Perhaps https://learn.microsoft.com/en-ca/windows/win32/api/winuser/nf-winuser-getasynckeystate?redirectedfrom=MSDN might be usable to detect and fix the expected state 🤔

rpnfan commented 3 weeks ago

Unfortunately this bug isn't easily actionable without consistent and precise steps.

I have noticed weirdness, mostly with administrator applications. It seems presses or releases are missed and then the Kanata and/or application and/or OS keystate gets messed up. Doesn't seem easy to fix though.

I have problems also on a laptop where I do not have admin rights.

But I just found a way to reproduce one specific error:

0) US international keyboard layout on Windows active 1) Run kanata_gui (with elevated rights) 2) press RightAlt + r, that will output ® and it will mess up the keyboard chain (Windows and/ or Kanata) 3) normal characters cannot be typed any longer, another ® or ñ (RightAlt +n) for example will still work 4) reloading the config clears the problem

Now the interesting part. Trying the same with the interception driver active and running kanata_wintercept (instead of kanata_gui) will not give any problems!

Also when using kanata_winIOv2 (standard rights) instead of the GUI version I get the same problems, but restarting the winIOv2 version does not fix the problem. Only when I run the GUI version again the problem is gone.

Can you reproduce the problem?

jtroo commented 3 weeks ago

Unfortunately this bug isn't easily actionable without consistent and precise steps. I have noticed weirdness, mostly with administrator applications. It seems presses or releases are missed and then the Kanata and/or application and/or OS keystate gets messed up. Doesn't seem easy to fix though.

I have problems also on a laptop where I do not have admin rights.

But I just found a way to reproduce one specific error:
0. US international keyboard layout on Windows active

1. Run kanata_gui (with elevated rights)

2. press RightAlt + r, that will output ®   and it will mess up the keyboard chain (Windows and/ or Kanata)

3. normal characters cannot be typed any longer, another ® or ñ  (RightAlt +n) for example will still work

4. reloading the config clears the problem
Now the interesting part. Trying the same with the interception driver active and running kanata_wintercept (instead of kanata_gui) will not give any problems!

Also when using kanata_winIOv2 (standard rights) instead of the GUI version I get the same problems, but restarting the winIOv2 version does not fix the problem. Only when I run the GUI version again the problem is gone.

Can you reproduce the problem?

Is this one fixable by one of the altgr options? https://github.com/jtroo/kanata/blob/main/docs/config.adoc#windows-only-windows-altgr

gerhard-h commented 3 weeks ago

your problem seems to be a hanging control or alt key. If the altgr options work for you - thats the best.

I switched to interception because some time ago, so my memory is not perfect any more.

My workaround was: not using altgr-options / not include ralt in defsrc / use process-unmapped-keys:no

jtroo commented 2 weeks ago

An aspect of this might be fixed by #1324

rpnfan commented 2 weeks ago

Thanks Gerhard and jtroo. The way to reproduce the problem with AltGr is just an example I found which allowed to trigger the problem. I normally do not use AltGr-codes at all, as they sooner or later make problems and also for touch-typing AltGr is a bad idea IMO, when there is only the right-hand side (not easy to reach) key placement.

I also have the problem that Ctrl-key seems to hang or the same weird behavior you see with the AltGr example above. I can not tell exactly when the keyboard chain (Kanata and/ or Win 11?) gets messed up. I have the impression it is more likely to happen, when I press one key rapidly a few times, but I have no way to reproduce it all times. I think it happens a few times in a week to me. Workaround is to reload the Kanata config and wait a few seconds. Not the best option, but for now I live with that, because I am super happy to be able to realize my custom keyboard layout and navigation layers with Kanata on any Win machine and can use it with the laptop keyboard.

@Gerhard: I tried the interception driver, but that will force me to do a full reboot in one of the cases the driver shuts up (keyboard reconnects). So that is not an option as long there is no interception driver without that limitation.

An aspect of this might be fixed by #1324

Thanks. That is a fix which will be applied in an upcoming release then, right? I am not a programmer and do not use Github that much, so do not know if/ how I can try a patch, which was not made available in an official release yet.

jtroo / kanata