Bug: mapping media keys does not work (MediaPlayPause, MediaTrackNext etc.)

[wis]

Requirements

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

Describe the bug

I'm trying to remap the functionality of the media keys on my keyboard and my headphones:

(deflayermap (mediaPlaybackControlLyr)
$p    (push-msg toggle_media_playback)
$H    (push-msg media_previous)
$L    (push-msg media_next)
MediaPlayPause          (push-msg toggle_media_playback)
MediaTrackPrevious      (push-msg media_previous)
MediaTrackNext          (push-msg media_next)
(t! escSpc)
)

The first 3 mappings work as expected, the next 3 don't. pressing the key does not even show that you pressed it in the --debug logs in Kanata's output.

Relevant kanata config

⬆️

To Reproduce

1. map MediaPlayPause, MediaTrackNext or MediaTrackNextPrevious in your Kanata config
2. press any of the keys to see if it does anything or shows in --debug logs output

Expected behavior

Media keys to do what I map them to when I press them.

Kanata version

kanata 1.7.0-prerelease-1 (last commit as of now 7adab8a )

Debug logs

Kanata does not output debug logs when I press down or release a media key. like it does for other keys.

Operating system

Windows 11

Additional context

• I compiled Kanata with: cargo build --features win_sendinput_send_scancodes,win_llhook_read_scancodes --release
  (llhook, not interception)
• Pressing the media keys on my keyboard and my headphones when using the web tool mentioned in the docs (7adab8a) shows the expected key names that I mapped (MediaPlayPause, MediaTrackNext, MediaTrackPrevious).
• Edit: I also tested with Kanata compiled without the above feature flags, just: cargo build --release, and it behaves the same, so the issue is not specific to those feature flags.

[jtroo]

If it's not showing in debug logs I think it might not be interceptable via the llhook mechanism, likely Windows OS doesn't pass it along.

[wis]

Does this mean it may require using some other mechanism or OS APIs that apps like Spotify or Chromium use to hook into the media keys on Windows?

[jtroo]

Does this mean it may require using some other mechanism or OS APIs that apps like Spotify or Chromium use to hook into the media keys on Windows?

My guess would be that apps can receive it as the focused window but background tasks can't receive it. That's what hooks are for; to allow background task to intercept and modify before reaching focused app. But if it doesn't work in hooks then likely not much option. I suppose we could see if rawinput might work.

[wis]

I looked into this, it appears on Windows (or at least starting with Windows 10), media keys can not be intercepted with regular global key hooks*, if I understood correctly, Windows has an API called Media Transport Controls (MTC), applications like media players or browsers that want to handle these events must register explicitly with MTC to receive them.

I don't think this API allows hooking into key events for media keys like key down or up, which Kanata requires for some of its features like triggering fake/virtual keys on key release or as soon as a key is pressed, so if you would want to add support for binding to media key presses on Windows*, I don't think media key mappings would/can support all the features of Kanata.

*(I mean without/besides using the Interception driver/mechanism)

Edit: it appears rawinput can capture media key events, but can not intercept/block the events (meaning other applications can still receive these key events).

[jtroo]

Thanks for doing the research!

[wis]

I thought I should make it known that I just tested the interception variant of Kanata and still the debug logs do not show any logs* to indicate that Kanata detects that a media key is pressed or released.
So I think it would be more appropriate to remove the llhook tag, or maybe it would be more appropriate to tag it with both the llhook tag and the wintercept tag.

*logs like these:

17:58:52.9641 [DEBUG] (1) kanata_state_machine::kanata::windows::interception: got stroke Keyboard { code: Comma, state: DOWN, information: 0 }
17:58:52.9641 [DEBUG] (1) kanata_state_machine::kanata::windows::interception: sending KeyEvent { code: KEY_COMMA (188), value: Press } to processing loop
17:58:52.9642 [DEBUG] (3) kanata_state_machine::kanata: process recv ev KeyEvent { code: KEY_COMMA (188), value: Press }