Behaviour in the presence of OS-level remapping is inconsistent in Windows-LLHOOK

[storvik]

I've been using kanata for a while and it has always served me well, but after changing layout to colemak-dh I've run into some issues setting up home row mods. It seems that kanata still interprets keys in qwerty despite changing layout. This is a tough one to explain so bear with me.

I type on a qwerty keyboard (physically), but my layout is set to
VC Keymap: us
X11 Layout: us
X11 Model: pc105
X11 Variant: colemak_dh
X11 Options: ctrl:nocaps

Here is a small example config

(defalias
  a (tap-hold 200 200 a lmet)
  r (tap-hold 200 200 r lalt)
  s (tap-hold 200 200 s lctl)
  t (tap-hold 200 200 t lsft)
  n (tap-hold 200 200 n rsft)
  e (tap-hold 200 200 e rctl)
  i (tap-hold 200 200 i lalt)
  o (tap-hold 200 200 o lmet)

  caps (tap-hold 200 200 esc lctl)
)

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

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

I now can type in colemak but home row mods are not working correctly. For example the colemak n key which is placed at the qwerty j wont trigger shift when hold. Instead the qwerty n key, which is the colemak k key triggers shift. Here is the log when starting kanata and pressing colemak n

21:40:45 [INFO] kanata v1.0.7 starting
21:40:45 [INFO] process unmapped keys: false
21:40:45 [INFO] config parsed
21:40:45 [INFO] Created device "/dev/input/event19"
21:40:45 [INFO] Sleeping for 2s. Please release all keys and don't press additional ones.
21:40:47 [INFO] entering the processing loop
21:40:47 [INFO] entering the event loop
21:40:47 [INFO] Init: catching only releases and sending immediately
21:40:48 [INFO] Starting kanata proper
21:40:50 [DEBUG] (2) kanata::kanata: key press     J
21:40:50 [DEBUG] (2) kanata::oskbd::linux: input ev: InputEvent { time: SystemTime { tv_sec: 1665690050, tv_nsec: 913969000 }, kind: Key(KEY_J), value: 1 }
n21:40:50 [DEBUG] (2) kanata::kanata: key release   J
21:40:50 [DEBUG] (2) kanata::oskbd::linux: input ev: InputEvent { time: SystemTime { tv_sec: 1665690050, tv_nsec: 985935000 }, kind: Key(KEY_J), value: 0 }
21:40:53 [DEBUG] (1) kanata::oskbd::linux: input ev: InputEvent { time: SystemTime { tv_sec: 1665690053, tv_nsec: 982023000 }, kind: Key(KEY_LEFTCTRL), value: 1 }
21:40:54 [DEBUG] (2) kanata::kanata: key press     X
21:40:54 [DEBUG] (2) kanata::oskbd::linux: input ev: InputEvent { time: SystemTime { tv_sec: 1665690054, tv_nsec: 306125000 }, kind: Key(KEY_X), value: 1 }

I was surprised to find this as it seems to work correctly in windows. Could it be that kanata is interfering with how linux (sway and wayland btw) is translating between qwerty / colemak?

Sorry for the somehow vague bug description, and thank you for your work on this project.

[jtroo]

Thanks for the kind words 🙂.

Summary

I was surprised to find this as it seems to work correctly in windows. Could it be that kanata is interfering with how linux (sway and wayland btw) is translating between qwerty / colemak?

Yes I believe this is the correct interpretation and it's somewhat by design.

More detail

I haven't tested your exact setup, but here's what's going on.

There are two different types of mechanism that software like kanata can use to remap keys.

1. OS kernel
2. OS userland

The mechanism kanata uses on Linux is in the OS kernel (/dev/input and /dev/uinput) whereas on Windows by default it's in OS userland (WH_KEYBOARD_LL). Aside: the Interception driver on Windows uses a kernel mechanism.

That kanata on Linux uses the kernel mechanism is actually a good thing because there's less weirdness in kanata's behavior on Linux. The consequence of this for Linux is that any X11 level remapping e.g. xmodmap will be done after all of kanata's processing; kanata will operate on the actual physical keys being sent in, and then xmodmap remaps the outputs. This is in contrast to the Windows WH_KEYBOARD_LL mechanism which will trigger after Windows has already mapped keys to Colemak-DH.

Two possible workarounds are:

• Do the Colemak-DH remapping inside kanata instead of the OS level, like the Dvorak example in the new guide
  • This has the advantage of having a cross-platform configuration file, but on Windows the remapping will no longer work in Administrator-privileged applications unless you're using Interception (which also has other issues)
• On Linux, remap the physical keys and on Windows, remap the Colemak-DH keys
  • This has the disadvantage different configurations (or two different layers in the same configuration) for the two different operating systems

The problem is actually more on the Windows side than the Linux side because Windows doesn't have a good kernel-level mechanism for kanata to make use of. I've entertained the idea of writing my own Interception-like kernel keyboard driver for Windows but haven't bit the bullet yet.

[storvik]

Thank you for the detailed answer!

I actually thought about doing the Colemak-DH mapping in Kanata entirely. When first starting with Colemak I found Kanata to be the best approach, as I was already using it for home row mods. However I did run into issues when configuring.

• I'm norwegian, and using a nordic qwerty keyboard (iso) many keys with special characters does not match Colemak and US qwerty. Therefore I must switch to US qwerty before remapping to Colemak in Kanata.
• When switching to US qwerty layout I could not figure out a nice way to get æ ø å working correctly. Need those to type in Norwegian. Colemak however has all these by default, that's why I for instance can use Kanata to output AltGr+w to get å.

I will fiddle around some more hoping to find a solution to these problems. As said above it would be great to just rely on Kanata when it comes to Colemak. Really enjoy Kanata on both windows and Linux and it's already become a big part of my workflow in general.

[br-lemes]

I'm not sure I understood your issue.

I'm Brazilian using ABNT2 Keyboard (Brazilian qwerty). I keep my system configured as ABNT2 qwerty. But in Kanata configuration file I need to use the ; character where I want the ç character. I use evtest to find out what I need instead of what.

I use:

(defsrc
	q w f p b  j l u y ;
	a r s t g  m n e i o
	z x c d v  k h , . ro
)

(deflayer base
	q w f p b  j l u y ;
	a r s t g  m n e i o
	z x c d v  k h , . ro
)

This way I use Colemak-DH but the system still thinks it's the default Brazilian ABNT2 qwerty. The ro key is the slash key in these keyboards. There is no other weird settings because it's on other layers. But I need to use ] to output [ and \ to output ] and so on...

[storvik]

I've set up kanata similar to @br-lemes. System is now set to US international. This gives me access to æøå using AltGr combinations and unlike norwegian qwerty, mappings of special characters are the same as colemak. Ex (multi ralt w) in kanata is å.

Only issue with this approach is that some windows applications does not like (multi ralt w). So far I have issues in VcXsrv and Outlook. I'm not sure, but this may be related to the explanation here.

[gerhard-h]

I would suggest (and use myself) tap-hold-diacrit like
ao (tap-hold 200 140 a (macro A-C-w) ) ;; å

It's more intuitive than learning the random US international shortcuts
And it's also faster and more convinient to type