Feature request: make kanata read+process injected inputs that don't originate from itself

[iamsergio]

Requirements

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

Describe the bug

I've installed kanata via cargo: cargo install kanata --features cmd

It works well for most keys, but not for the multimedia keys (pp prev next).
These keys do work on Linux.

I also tried windows_key_tester.exe, got some codes, and used deflocalkeys-win, but doesn't work either.

Any clue how to debug further ?
Thanks

Relevant kanata config

;; codes detected by windows_key_tester.exe
(deflocalkeys-win
  foo1 179
  foo2 177
  foo3 176
)

;; On Linux these work fine, no need for codes: pp prev next 
(defsrc foo1 foo2 foo3 a)

(deflayer start 1 2 3 4)

To Reproduce

Try to get any multimedia keys to remap, on Windows 11.

Expected behavior

.

Kanata version

1.5.0

Debug logs

2024-03-11T12:29:32.8593004Z [INFO] kanata v1.5.0 starting
2024-03-11T12:29:32.8593812Z [INFO] using LLHOOK+SendInput for keyboard IO
2024-03-11T12:29:32.8594433Z [INFO] You may forcefully exit kanata by pressing lctl+spc+esc at any time. These keys refer to defsrc input, meaning BEFORE kanata remaps keys.
2024-03-11T12:29:32.8597531Z [DEBUG] (1) kanata_parser::cfg: custom mapping: foo1 179
2024-03-11T12:29:32.8598288Z [DEBUG] (1) kanata_parser::cfg: custom mapping: foo2 177
2024-03-11T12:29:32.8598801Z [DEBUG] (1) kanata_parser::cfg: custom mapping: foo3 100
2024-03-11T12:29:32.8599443Z [INFO] process unmapped keys: false
2024-03-11T12:29:32.8600126Z [WARN] DANGER! cmd action is enabled.
2024-03-11T12:29:32.860065Z [DEBUG] (1) kanata_parser::cfg::alloc: freeing allocations of length 0
2024-03-11T12:29:32.8613059Z [INFO] config parsed
2024-03-11T12:29:32.8613709Z [INFO] Asking Windows to improve timer precision
2024-03-11T12:29:32.8614497Z [INFO] Asking Windows to increase process priority
2024-03-11T12:29:32.86153Z [INFO] Sleeping for 2s. Please release all keys and don't press additional ones.
2024-03-11T12:29:34.8620136Z [INFO] entering the processing loop
2024-03-11T12:29:34.8628999Z [INFO] Init: catching only releases and sending immediately
2024-03-11T12:29:35.4158688Z [INFO] Starting kanata proper

Operating system

Windows 11

Additional context

No response

[jtroo]

This works for me on Win11 using v1.5.0. Are you using a keyboard with combined f-key/media keys, and are using the f-keys?

Test config and debug logs

(defsrc
  pp prev next
)
(deflayer base
  a b c
)

2024-03-12T00:54:03.462594-07:00 [INFO] kanata v1.5.0 starting
2024-03-12T00:54:03.4628531-07:00 [INFO] using LLHOOK+SendInput for keyboard IO
2024-03-12T00:54:03.4630092-07:00 [INFO] You may forcefully exit kanata by pressing lctl+spc+esc at any time. These keys refer to defsrc input, meaning BEFORE kanata remaps keys.
2024-03-12T00:54:03.4635695-07:00 [INFO] process unmapped keys: false
2024-03-12T00:54:03.463856-07:00 [DEBUG] (1) kanata_parser::cfg::alloc: freeing allocations of length 0
2024-03-12T00:54:03.4652691-07:00 [INFO] config parsed
2024-03-12T00:54:03.4655061-07:00 [INFO] Asking Windows to improve timer precision
2024-03-12T00:54:03.4657586-07:00 [INFO] Asking Windows to increase process priority
2024-03-12T00:54:03.4660562-07:00 [INFO] Sleeping for 2s. Please release all keys and don't press additional ones.
2024-03-12T00:54:05.4668521-07:00 [INFO] entering the processing loop
2024-03-12T00:54:05.4679962-07:00 [INFO] Init: catching only releases and sending immediately
2024-03-12T00:54:06.3807258-07:00 [INFO] Starting kanata proper
2024-03-12T00:54:08.894984-07:00 [DEBUG] (1) kanata::kanata::windows::llhook: event loop: KeyEvent { code: KEY_PLAYPAUSE, value: Press }
2024-03-12T00:54:08.8960964-07:00 [DEBUG] (2) kanata::kanata: process recv ev KeyEvent { code: KEY_PLAYPAUSE, value: Press }
2024-03-12T00:54:08.896532-07:00 [DEBUG] (2) kanata::kanata: key press     A
2024-03-12T00:54:08.9577226-07:00 [DEBUG] (1) kanata::kanata::windows::llhook: event loop: KeyEvent { code: KEY_PLAYPAUSE, value: Release }
2024-03-12T00:54:08.9591666-07:00 [DEBUG] (2) kanata::kanata: process recv ev KeyEvent { code: KEY_PLAYPAUSE, value: Release }
2024-03-12T00:54:08.9594836-07:00 [DEBUG] (2) kanata::kanata: key release   A
2024-03-12T00:54:10.2824187-07:00 [DEBUG] (1) kanata::kanata::windows::llhook: event loop: KeyEvent { code: KEY_PREVIOUSSONG, value: Press }
2024-03-12T00:54:10.2843107-07:00 [DEBUG] (2) kanata::kanata: process recv ev KeyEvent { code: KEY_PREVIOUSSONG, value: Press }
2024-03-12T00:54:10.284759-07:00 [DEBUG] (2) kanata::kanata: key press     B
2024-03-12T00:54:10.3454956-07:00 [DEBUG] (1) kanata::kanata::windows::llhook: event loop: KeyEvent { code: KEY_PREVIOUSSONG, value: Release }
2024-03-12T00:54:10.3472755-07:00 [DEBUG] (2) kanata::kanata: process recv ev KeyEvent { code: KEY_PREVIOUSSONG, value: Release }
2024-03-12T00:54:10.3477247-07:00 [DEBUG] (2) kanata::kanata: key release   B
2024-03-12T00:54:11.0239907-07:00 [DEBUG] (1) kanata::kanata::windows::llhook: event loop: KeyEvent { code: KEY_NEXTSONG, value: Press }
2024-03-12T00:54:11.0260275-07:00 [DEBUG] (2) kanata::kanata: process recv ev KeyEvent { code: KEY_NEXTSONG, value: Press }
2024-03-12T00:54:11.0264147-07:00 [DEBUG] (2) kanata::kanata: key press     C
2024-03-12T00:54:11.0946051-07:00 [DEBUG] (1) kanata::kanata::windows::llhook: event loop: KeyEvent { code: KEY_NEXTSONG, value: Release }
2024-03-12T00:54:11.0960306-07:00 [DEBUG] (2) kanata::kanata: process recv ev KeyEvent { code: KEY_NEXTSONG, value: Release }
2024-03-12T00:54:11.0964396-07:00 [DEBUG] (2) kanata::kanata: key release   C

[iamsergio]

I tried with both a keyboard with combined ( f-key/media ) and one without f-key.
I suspect Windows is intercepting the media keys somehow.

I've since used other keys and I'm happy. So I'm closing this.

Thank you.

[eugenesvk]

Could this please be reopened?

I have the same issue (keyboard with a dedicated row of media keys). They don't get recognized by default, although using aliases with numbers from the key tester work for OUTput (1 does mute), but not for recognizing input
Also keys are recognized by the windows_key_tester tool, so it's a bit strange (and if I try to use the code 173 in defsrc, I get a dupe error, which makes sense since in kanata's source code 173 is also mapped to the mute key, so using vvmute is a dupe)

(defcfg)
(deflocalkeys-win vvmute 173 )
(defsrc
  pp mute voldwn volu
  1
)
(deflayer base
  a b c d
  vvmute
)

[jtroo]

As a note I still can't reproduce this.

I tried using my laptop's builtin media keys mute volu vold as well as outputting the keys from interception and reading them again in llhook, and it works correctly for me 🤷

[eugenesvk]

Do you remember what's different between the hook that's used in the windows_key_tester utility (which can detect presses) and kanata proper? Think this might be the easier way to track it

[jtroo]

They're just about the exact same code.

The only thing I can think of is that your multimedia keys are somehow being injected instead of sent by the hardware, and thus is not read by kanata:

kanata/windows_key_tester/src/llhook.rs

Lines 62 to 64 in 33011ca

	let is_injected = hook_lparam.flags & LLKHF_INJECTED != 0;
	let key_event = InputEvent::from_hook_lparam(hook_lparam);
	log::info!("{code}, {wparam:?}, {is_injected}, {key_event:?}");

[eugenesvk]

You're correct, they do weirdly show up as injected (why would hardware keys behave like software?)

And I see in AHK log that they're also tagged as "artificial" (which tracks the same LLKHF_INJECTED flag), though AHK is able to rebind them - is it because AHK tags its own input events via another mechanism (e.g., as far as I know it tags its own events with sendlevels), so it's able to rebind artificial media keys while also being able to ignore its own events to avoid infinite loops?

Could kanata do something like this - tag its own output in some other boolean field and ignore only that instead of ignoring all artificial events, which in this case leads to some real hardware input mascarading as software being ignored?

[jtroo]

Sure, something similar to my espanso patch might work:

jtroo/espanso@c55af9c