Bug 403636

Summary: Media Pause button doesn't work properly
Product: [Frameworks and Libraries] frameworks-kglobalaccel Reporter: Eduardo Rocha <edarocha1324>
Component: generalAssignee: kdelibs bugs <kdelibs-bugs>
Status: RESOLVED FIXED    
Severity: minor CC: akozlovskiy119, andryandrew, andy, aspotashev, astronautr, bugs.kde.org.facelift226, bugzilla, craig, jsardid, kde, kde, loganturner547, lucas.olvr.campos, mcnichol, milas.robin, nate
Priority: NOR Keywords: usability
Version: 5.111.0   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=476568
Latest Commit: Version Fixed In: 5.81
Sentry Crash Report:
Attachments: KDE Shortcuts screenshot
Screenshot of the KDE System Settings window for shortcuts

Description Eduardo Rocha 2019-01-26 19:53:16 UTC
SUMMARY
I have a Bluetooth headset that has media buttons (play/pause, next, previous and volume up and down). All buttons work, but there's a problem when pressing the play/pause button: It only works every second time.

That is, I press the button -> music stops; I press again -> nothing happens; I press again -> music resumes; I press again -> nothing happens.

I found out (using xev) that my headset alternates sending X86AudioPlay and XF86AudioPause on every press. When XF86AudioPause is sent, nothing happens.

One can say "Yeah, on the Global Shortcuts it's configured to only listen to Media Play, so you should add Media Pause to it too". Well, were it been that simple I wouldn't have written this bug report :D

When I replace the shortcut to be Media Pause (or add it as a global alternative), the shortcut is saved, but nothing happens. That is, the bug still occurs. When it's added as an alternative, only every second press pauses/resumes the player. When replacing it with Media Play, the play/pause button doesn't work at all.

When using xdotool to emulate the keypress it doesn't work either.

I fiddled with the shortcuts a little bit and I found out this problem doesn't only apply to the media player.

Any shortcut I set the trigger to be Media Pause (XF86AudioPause) doesn't work. Example: I create a custom shortcut (e.g. open konsole) and set it's trigger to be Media Pause. It listens to the key press, I can configure the shortcut properly, but the shortcut itself doesn't work.

When I do the same thing with Media Play (XF86AudioPlay), the shortcut works as intended (e.g. konsole is opened).

STEPS TO REPRODUCE
1. Set a shortcut's trigger to be Media Pause (either an existing or a new shortcut)
2. Press the Media Pause button (or emulate it with xdotool)

OBSERVED RESULT
Nothing happens

EXPECTED RESULT
The shortcut executes its assigned action

SOFTWARE/OS VERSIONS
Linux: Arch Linux (Linux Version 4.20.3)
KDE Plasma Version: 5.14.5
KDE Frameworks Version: 5.54.0
Qt Version: 5.12.0
Comment 1 Synthetic451 2019-09-18 08:23:59 UTC
I am also experiencing this issue on my Sony WH1000XM2 headphones. The play/pause button works great in Gnome but works every other time in KDE.
Comment 2 Luca Weiss 2019-10-14 11:35:50 UTC
I'm experiencing the same issue on Arch Linux (Plasma 5.16.5, Frameworks 5.62.0, Qt 5.13.1, Kernel 5.3.5). According to evtest my bluetooth headphones emit KEY_PLAYCD and KEY_PAUSECD and the music just pauses/resumes with the KEY_PLAYCD events and nothing happens with the KEY_PAUSECD ones.
Comment 3 MILAS Robin 2019-11-10 08:35:06 UTC
Created attachment 123818 [details]
KDE Shortcuts screenshot

Same problem with my laptop keyboard,
Keys are correctly detected by xev and KDE Settings but they do not work
Comment 4 MILAS Robin 2019-11-23 03:02:15 UTC
My bad in my case it was due to a chrome plugin intercepting the Media events...
Comment 5 craig 2020-02-04 15:48:30 UTC
I experience the same issue with:
Operating System: Kubuntu 19.10
KDE Plasma Version: 5.17.5
KDE Frameworks Version: 5.66.0
Qt Version: 5.12.4
Kernel Version: 5.3.0-26-generic
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-8550U CPU @ 1.80GHz
Memory: 15,4 GiB of RAM

And the Sony WH-1000XM3

Everything works great with my phone
Comment 6 Lucas 2020-05-10 19:32:07 UTC
Same problem on my notebook under Neon 5.18.5 and Kubuntu 20.04.
Comment 7 Lucas 2020-05-10 19:40:58 UTC
(In reply to lucas.olvr.campos from comment #6)
> Same problem on my notebook under Neon 5.18.5 and Kubuntu 20.04.

Like MILAS Robin said, it's a Chrome problem. Disabling native Chromium/Chrome media handling in chrome://flags/#hardware-media-key-handling solves the issue.
Comment 8 andrea 2020-06-20 17:38:15 UTC
I confirm having the same issue: both my headsets alternatively send AudioPlay/AudioPause events, but only AudioPlays are ever handled by plasma.

This has nothing to do with chromium, the issue is the same for every player.
Comment 9 andrea 2020-06-20 17:51:56 UTC
As a workaround, you can install xdotool and xbindkeys (https://wiki.archlinux.org/index.php/Xbindkeys) and append to your ~/.xbindkeysrc file the following:

"xdotool key --clearmodifiers XF86AudioPlay"
    c:209

which will map the XF86AudioPause event (code 209) to an xdotool call issuing a XF86AudioPlay key. Reload xbindkeys with xbindkeys --poll-rc .
Comment 10 Alexander Potashev 2020-12-20 19:43:17 UTC
dupe of https://bugs.kde.org/show_bug.cgi?id=426147
Comment 11 JesseM 2020-12-28 23:10:40 UTC
(In reply to andrea from comment #9)
> As a workaround, you can install xdotool and xbindkeys
> (https://wiki.archlinux.org/index.php/Xbindkeys) and append to your
> ~/.xbindkeysrc file the following:
> 
> "xdotool key --clearmodifiers XF86AudioPlay"
>     c:209
> 
> which will map the XF86AudioPause event (code 209) to an xdotool call
> issuing a XF86AudioPlay key. Reload xbindkeys with xbindkeys --poll-rc .

I can confirm andrea's workaround fixes the problem in Ubuntu 20.04 running KDE. Just installed the packages recommended, made a new ~/.xbindkeysrc file with just the contents andrea mentioned and everything works now! thank you andrea!
Comment 12 Nate Graham 2021-02-24 19:52:42 UTC
*** Bug 426147 has been marked as a duplicate of this bug. ***
Comment 14 andrea 2021-02-25 13:44:46 UTC
In my system (Arch, Plasma 5.21) the new shortcut indeed appears on system settings, but issuing

`xdotool key XF86AudioPause`

Still doesn't pause the stream, while XF86AudioPlay does. If I bind the "pause" action to another key, it works as expected.
Comment 15 David Redondo 2021-02-25 13:45:31 UTC
Thanks for the info!
Comment 16 Bug Janitor Service 2021-03-08 11:33:03 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kwindowsystem/-/merge_requests/15
Comment 17 David Redondo 2021-03-08 12:22:11 UTC
Git commit 53daf6bff454bf8c0a2cb18a57587de5d9e93887 by David Redondo.
Committed on 08/03/2021 at 11:22.
Pushed by davidre into branch 'master'.

Add MediaPause key to mapping

We were missing it.

M  +1    -0    src/platforms/xcb/kkeyserver.cpp

https://invent.kde.org/frameworks/kwindowsystem/commit/53daf6bff454bf8c0a2cb18a57587de5d9e93887
Comment 18 andrea 2021-04-29 19:27:19 UTC
I just updated to 5.21 and I can confirm everything works as expected now without any workaround. Thank you!
Comment 19 Logan Turner 2023-10-25 06:32:46 UTC
Created attachment 162554 [details]
Screenshot of the KDE System Settings window for shortcuts

The issue has seemingly reappeared in the latest KDE Plasma release. Upon login, media keys are detected and funtion normally. However, after closing the app and reopening it or another media player, the keys stop responding. I have tested this with both my Keychron K2 V2 keyboard and JBL T660NC headphones. For some reason, there are multiple entries for playing and pausing media. Changing these shortcuts does not affect the bug as it persists regardless. These keys were fully functional in the previous version.

System info:
OS: Arch Linux
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.111.0
Locale: en_NZ.UTF-8
Kernel: 6.5.8-zen1-1-zen
CPU: Intel Core i5-1135G7 (4C 8T)
GPU: Intel Iris Xe (80 exe. units)
Memory: 16GB 3200MHz DDR4 SODIMM (2x 8GB)
System: HP ProBook 430 G8 (567F3PA)
Comment 20 Nate Graham 2023-10-25 14:16:39 UTC
This is a fairly old bug report and the code has changed a lot since it was reported. There's a very good chance the issue you're experiencing is caused by something else, even if the outward symptoms look and feel the same. Can you please submit a new bug report? Thank you!