Some "media keys" not recognized in key mapping?

[wmorrison]

I don't know whether this is a MythTV issue, or an OS issue (configuration or capability,) or just something that's not possible with Linux/MythTV.

I have a remote that transmits "Windows Media Keys." Those "extra" keys on some keyboards such as play, pause, ff/rw, etc.

Some of them, such as pause, can be mapped in MythTV. Setup->Key Mappings, find the context and action, enter, enter, it waits for a key to be pressed, then asks for confirmation to map this key.

Others, such as play, do not register. It waits for a key but never recognizes when "play" is pressed.

Command-line "showkey" and other methods of scanning input show that pressing "play" is indeed sending a code.

So I don't know whether the problem is that MythTV only recognizes a certain set of key codes, or the OS doesn't "translate" them to something MythTV is looking for, or what.

Any ideas?

[wesnewell]

Likely not defined in your distro KB layout. In buntu's for instance, iirc the default KB layout is generic 105, which doesn't recognize multimedia keys. In buntu's it's Settings> Keyboard>Layout to set KB model.

[blm-ubunet]

I wouldn't trust showkeys? or any of the X11 utilities (xbindkeys, xev etc) as they now high level event consumers.

Are you sure the key events you see are complete?
I find that OS or systemd or other (pulseaudio, display-manager ?) steal the special keypress events & remove/modify the keycodes.

Try 'keytest' (part of Esekeyd) as this programs reveals all the keyboard keys (volume, eject - everything).

If the key events are complete (xev) then possibly you can use xmodmap to configure the extra keys so they appear in X as a standard key.

I use 'esekeyd' to control an external HT amp volume/mute from multimedia keyboard over USB-serial adapter.
AFACT 'esekeyd' is the only way to wrestle back control of 'volume' events from the desktop environment.