Arch Linux

Description:
My bluetooth headset has a play/pause button, which shows up in xev as

KeyPress event, serial 41, synthetic NO, window 0x5200001,
root 0x263, subw 0x0, time 5609283, (250,278), root:(2721,768),
state 0x10, keycode 208 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
XKeysymToKeycode returns keycode: 172
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 41, synthetic NO, window 0x5200001,
root 0x263, subw 0x0, time 5609294, (250,278), root:(2721,768),
state 0x10, keycode 208 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
XKeysymToKeycode returns keycode: 172
XLookupString gives 0 bytes:
XFilterEvent returns: False

However, while my keyboard play/pause key works globally, as well as locally, the headset play/pause button only work if the application has focus. This means I can map the key, but not use it as a global hotkey. I have first thought that it's a bug with deadbeef [1], but we have debugged the issue as far as we could and the keypress never reaches deadbeef.

Next suspect was KDE or other programs "stealing" the keypress - I've tried a fresh, bare openbox session with only deadbeef started, and the result was the same - no keypress event registered. I then did a search on XF86AudioPlay + key code 208 and found this ubuntu bug [2]. Thing is, XGrabKey seems to be picking it up correctly, as I was able to work around the issue with xbindkeys.

xbindkeys also recognizes the key as XF86AudioPlay (just like my keyboard key), the only difference between these two is that the BT key has code 208 and the kb key has the code 172.
The weirdest thing is, the rest of my headset buttons (prev/next) work as expected. There is also no issue with the key on windows or android. So it seems that it is a bug, but I lack the knowledge to pinpoint whether it's in Xorg, the bluetooth daemon or somewhere else (so I picked system as the category).

Do tell if you need any more info.

Steps to reproduce:
- pair a BT headset that uses key code 208 for XF86AudioPlay
- start any program that reacts to a _global_ keymap of XF86AudioPlay
- attempt to trigger a keypress event

[1] https://github.com/Alexey-Yakovenko/deadbeef/issues/1180
[2] https://bugs.launchpad.net/ubuntu/+source/unity-settings-daemon/+bug/1397142