Bug: remapping arrow keys and sixpack results inn numberpad keys being pressed.

[blindelectron]

Requirements

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

Describe the bug

I was attempting to make a function layer for use with keybords with missing keys, wen I noted that when trying to remap arrow keys, as well as pageUp, pageDown, and other sixpack keys, Kanata would output numpad keys. EG: down arrow is numpad 2. It is important to note that I am using NVDA as I am visually impaired. I am unsure if NVDA could be causing the problem and am unsure of a way to test.

Relevant kanata config

(defsrc)
(deflayermap (baseLayer)
 caps ret
ret caps
comp (tap-hold 100 150 comp (layer-while-held functions))
f4 (tap-dance 200 (f4 A-f4))

)

(deflayermap (functions)
grv comp 1 f1 2 f2 3 f3 4 f4 5 f5 6 f6 7 f7 8 f8  9 f9 0 f10 - f11 = f12
w up
a lft
s down
d rght
h home
l end
j pgup
k pgdn
)

To Reproduce

1. Use the provided config.
2. Hold down the applications key.
3. Press the letter s. You should note that instead of pressing down arrow, it presses numpad 2.

Expected behavior

Pressing letter s while holding the applications key would press down arrow.

Kanata version

kanata 1.6.1

Debug logs

2024-07-26T10:36:30.7053456-05:00 [DEBUG] (1) kanata_state_machine::kanata::windows::llhook: event loop: KeyEvent { code: KEY_COMPOSE, value: Press }
2024-07-26T10:36:30.7063852-05:00 [DEBUG] (2) kanata_state_machine::kanata: process recv ev KeyEvent { code: KEY_COMPOSE, value: Repeat }
2024-07-26T10:36:30.7065805-05:00 [DEBUG] (2) kanata_state_machine::kanata::key_repeat: key outs for active layer-while-held: [KEY_COMPOSE];
2024-07-26T10:36:30.7066831-05:00 [DEBUG] (2) kanata_state_machine::kanata::key_repeat: empty layer-while-held outputs, probably transparent
2024-07-26T10:36:30.7067602-05:00 [DEBUG] (2) kanata_state_machine::kanata::key_repeat: key outs for default layer: [KEY_COMPOSE];
2024-07-26T10:36:30.7068398-05:00 [DEBUG] (2) kanata_state_machine::kanata::key_repeat: checking defsrc output
2024-07-26T10:36:30.7100529-05:00 [DEBUG] (1) kanata_state_machine::kanata::windows::llhook: event loop: KeyEvent { code: KEY_S, value: Press }
2024-07-26T10:36:30.7105082-05:00 [DEBUG] (2) kanata_state_machine::kanata: process recv ev KeyEvent { code: KEY_S, value: Press }
2024-07-26T10:36:30.7107426-05:00 [DEBUG] (2) kanata_state_machine::kanata: key press S
2024-07-26T10:36:30.819553-05:00 [DEBUG] (1) kanata_state_machine::kanata::windows::llhook: event loop: KeyEvent { code: KEY_S, value: Release }
2024-07-26T10:36:30.8210779-05:00 [DEBUG] (2) kanata_state_machine::kanata: process recv ev KeyEvent { code: KEY_S, value: Release }
2024-07-26T10:36:30.8212433-05:00 [DEBUG] (2) kanata_state_machine::kanata: key release S
2024-07-26T10:36:33.104137-05:00 [DEBUG] (1) kanata_state_machine::kanata::windows::llhook: event loop: KeyEvent { code: KEY_COMPOSE, value: Release }
2024-07-26T10:36:33.1057588-05:00 [DEBUG] (2) kanata_state_machine::kanata: process recv ev KeyEvent { code: KEY_COMPOSE, value: Release }

Operating system

Windows11

Additional context

Using NVDA screen reader

[jtroo]

Can you try the winiov2 or scancode_experimental variants?

[blindelectron]

@jtroo Both of these variants fix the problem, the expected now happens. I wonder if NVDA is trying to use the same mechanism as Kanata to intercept keyboard input? Odd since it has an option to deal with input from other applications, I may have to see if this is the case and see what can be done so this issue doesn't arise in the future for others.

[jtroo]

I don't think it's an issue with NVDA. It's a Windows issue with scancodes that have a variant that is extended and non-extended, when using virtual keys instead of scancodes for output.

Starting from 1.7.0 onwards the default kanata binary on Windows will be using scancode output.

[blindelectron]

@jtroo Good to here, I was not looking forward to getting back into Windows annoying accessibility stack. Thank you for your help, I am closing the issue as it seems that the problem is resolved.