bug: arrows (left,rght,up,down) send (4,6,8,2) on Windows Start Menu about kanata HOT 9 CLOSED

When kanata Windows hook version is running, navigation key codes skip the E0 and thus their code is detected as NumPad. (I guess).

When NumLock is active, most of the time, navigation keys still send navigation events to apps.

But in some apps like windows emoji panel, whatsapp, etc., they send NumPad event and write numbers.

When kanata is not running, the navigation key codes are detected correctly.
Workaround is to disable numlock or using kanata wintercept variant that sends the right key codes.

It would be nice if it could be fixed in the Windows hook so it can send the right key codes, but I don’t know if it’s possible.

from kanata.

I would also like to point out that new winiov2 variants do not have this problem!

from kanata.

My defsrc:

(defsrc
  esc  f1   f2   f3   f4   f5   f6   f7   f8   f9   f10  f11  f12        f13  f14  f15   f16  f17  f18  f19
  102d 1    2    3    4    5    6    7    8    9    0    -    =    bspc  ins  home pgup  nlck clr  kp/  kp*
  tab  q    w    e    r    t    y    u    i    o    p    [    ]    ret   del  end  pgdn  kp7  kp8  kp9  kp-
  caps a    s    d    f    g    h    j    k    l    ;    '    \                          kp4  kp5  kp6  kp+
  lsft grv  z    x    c    v    b    n    m    ,    .    /    rsft            up         kp1  kp2  kp3  kprt
  lctl lalt lmet           spc                 rmet ralt      rctl       left down rght  kp0       kp.
)

from kanata.

I've found that the workaround to this is to toggle NumLock. For some reason when I use NumLock on Windows, it doesn't actually affect the numpad buttons, e.g. kp2. It also doesn't affect the physical arrow buttons when not mapped. However, NumLock state does affect injected arrow keys and specifically only in the Windows start menu.

Very strange. Looking though the code I don't see anything particularly wrong either.

from kanata.

Aha! At least my immediate problem is solved! I realised that this was also the reason that I couldn't press "up" on Windows typing corrections/completions anymore; this is also fixed by toggling NumLock. 🚀

from kanata.

kmonad/kmonad#574 (comment)

Windows quirk, shift key overrides numlock. Linux doesn't have this issue.

There is currently no way of toggle numlock on key release so any macro that 1) uses kp keys 2) has shift and 3) needs to be held won't work.

from kanata.

I'm not sure if this one is the same bug because this affects pressing of the physical arrow keys rather than use of the numpad's alternate movement functionality.

It's still likely a Windows-only bug, but it seems to be more specific in the sense that particular Windows UI components handle injected arrow key events weirdly with NumLock.

from kanata.

I found this while working through the code for the interception driver. It turns out that at some layer, the standard nav keys are actually extended keycodes (uses E0 flag) with the base keycode mapping to the numpad layer. This is not how it looks in Linux or in the Windows hook layers though. Just interesting to note.

Since it's bug in the particular Windows UI components which are doing weird legacy stuff, I'll close this.

from kanata.

Sorry for necroposting. Another workaround would be to set

(defcfg
  process-unmapped-keys no
)

This, however, might have an impact on the behavior of other things; I have a vague memory of setting that to true because something went wrong with key rolls.

from kanata.