Ask Your Question
0

Duplicated media keys for the same function [Music Play/Pause] [closed]

asked 2016-01-13 07:40:57 -0500

updated 2016-01-14 04:47:33 -0500

I recently purchased a new bluetooth headset (Creative Aurvana Platinum). It has some media keys (Play/Pause, Next, Prev) but only Prev, and Next are working globally (system wide). The Play/Pause button doesn't work except with Totem (maybe VLC too) and it should be focused on.

I've also a media key button on my keyboard which works perfectly system wide. so I opened System Settings (GNOME control center) and opened the shortcuts to verify the assigned keys. I found that "Play (or play/pause)" is assigned for "Audio play", and "Pause Playback" is assigned to "Audio pause". so I changed the accelerator to the new button of my headset and I was astonished as it detected it as "Audio pause" which conflicts with the assigned value of "Pause Playback" but I assigned it anyway.

Now, the "Play/Pause" button of my headset works (sometimes), but the keyboard one doesn't work. so I fired up the xev to know exactly the button codes and differences between them. The following is the button of the headset:

KeyPress event, serial 41, synthetic NO, window 0x6a00001,
    root 0xd6, subw 0x0, time 660716097, (89,-23), root:(126,75),
    state 0x0, 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 0x6a00001,
    root 0xd6, subw 0x0, time 660716571, (89,-23), root:(126,75),
   state 0x0, keycode 208 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
   XKeysymToKeycode returns keycode: 172
   XLookupString gives 0 bytes: 
   XFilterEvent returns: False

The keyboard button is the following:

KeyPress event, serial 48, synthetic NO, window 0x6a00001,
    root 0xd6, subw 0x0, time 662269525, (1588,426), root:(1625,524),
    state 0x0, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 48, synthetic NO, window 0x6a00001,
   root 0xd6, subw 0x0, time 662269657, (1588,426), root:(1625,524),
   state 0x0, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
   XLookupString gives 0 bytes: 
   XFilterEvent returns: False

My first question is: How to assign 2 different buttons to the same shortcut as I don't need the pause shortcut and I don't have a separate key for it? (Of course, not using the System Settings Dialogue)

My second question is: Why the headset button doesn't play from the very first time (though it pauses correctly from the first time), though it sends the same keycode again and again?

EDIT: Looks like I was wrong and I've discovered some new details: The headset saves the last signal sent to the system (Play or Pause) and send the opposite. "xev" can't catch assigned shortcuts in GNOME control center too, I disabled the shortcuts to look into the "xev" result of both buttons (Headset and Keyboard). I found the both have different keycodes but same XF86 function (this is a result of xkeysym table). Still, for some reason, XF86AudioPlay which is issued from the keycode 208 ... (more)

edit retag flag offensive reopen merge delete

Closed for the following reason question is not relevant or outdated by Anass Ahmed
close date 2016-01-14 06:14:47.557167

1 Answer

Sort by ยป oldest newest most voted
1

answered 2016-01-14 06:11:06 -0500

After some troubleshooting here and there, I discovered that I was wrong. The headset issues (Play/Pause) signals accordingly (the opposite each time).

Xev can't catch the keys if it's already mapped (or at least gives some mapping notify that I can't understand) so I should disable shortcuts in GNOME Settings to see it correctly.

GNOME catches XF86AudioPlay from the keyboard button perfectly (and sometimes it stuck catching it). on the other hand, GNOME slips some signals from the headset XF86AudioPlay but catches all XF86AudioPause perfectly! This leads me to click on the button of my headset a few times to get it work which is a little bit frustrating.

I guess this has something to do with some algorithm GNOME uses to differentiate between Play/Pause toggling. Because Keyboard button uses only XF86AudioPlay but Headset button uses both XF86AudioPlay/Pause consecutively. I don't know how to log/know what happens on the GNOME side of things for now, but I think this question is expired now and doesn't express about the problem precisely.

edit flag offensive delete link more

Question Tools

1 follower

Stats

Asked: 2016-01-13 07:39:35 -0500

Seen: 527 times

Last updated: Jan 14 '16