This document contains a list of known issues which are unique to a given platform. The platform supported by the core maintainer (jtroo) are Windows 11 and Linux. Windows 10 is expected to work fine, but as Windows 10 end-of-support is approaching in 2025, jtroo no longer has any devices with it installed.
On Windows, there are two backing mechanisms that can be used
for keyboard input/output and they have different issues.
These will be differentiated by the words "LLHOOK" and "Interception",
which map to the binaries
kanata.exe and kanata_wintercept.exe respectively.
-
The emoji picker does not work properly
-
Mouse inputs cannot be used for processing or remapping
-
Some input key combinations (e.g. Win+L) cannot be intercepted before running their default action
-
OS-level key remapping behaves differently vs. Linux or Interception
-
Does not affect winiov2 variant
-
-
Certain applications that also use the LLHOOK mechanism may not behave correctly
-
AltGr can misbehave
-
NumLock state can mess with arrow keys in unexpected ways
-
Does not affect winiov2 variant
-
Workaround: use the correct numlock state
-
-
Without
process-unmapped-keys yes, using arrow keys without also having the shift keys indefsrcwill break shift highlighting-
Does not affect winiov2 variant
-
Workaround: add shift keys to
defsrcor useprocess-unmapped-keys yesindefcfg
-
-
Sleeping your system or unplugging/replugging devices enough times causes inputs to stop working
-
Some less-frequently used keys are not supported or handled correctly
-
Key repeats can occur when they normally wouldn’t in some cases
-
Unicode support has limitations, using xkb is a more consistent solution
-
Key actions can behave incorrectly due to the rapidity of key events
-
adjusting rapid-event-delay can potentially be a workaround
-
Macro keys on certain gaming keyboards might stop being processed
-
Context: search for
POTENTIAL PROBLEM - G-keysin the code. -
Workaround: leave
process-unmapped-keysdisabled and explicitly map keys indefsrcinstead
-