#1071717 gnome-settings-daemon: gsd-media-keys fires D-Bus MPris PlayPause message randomly

Package:
gnome-settings-daemon
Source:
gnome-settings-daemon
Description:
daemon handling the GNOME session settings
Submitter:
Andres Gomez Garcia
Date:
2024-05-29 12:21:03 UTC
Severity:
normal
#1071717#5
Date:
2024-05-24 07:08:28 UTC
From:
To:
Dear Maintainer,

I've some keyboard key combination mapped for doing the PlayPause
action.

Rarely, when I'm using the headphones for other use than music, for
example, attending a confcall, the music playback is activated
randomly.

After inspection with dbus-monitor, I see this message causing the
problem:

$ dbus-monitor 'interface=org.mpris.MediaPlayer2.Player'
signal time=1716534223.839734 sender=org.freedesktop.DBus -> destination=:1.6533 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.6533"
signal time=1716534223.839830 sender=org.freedesktop.DBus -> destination=:1.6533 serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameLost
   string ":1.6533"
method call time=1716534225.234537 sender=:1.78 -> destination=:1.621 serial=2411 path=/org/mpris/MediaPlayer2; interface=org.mpris.MediaPlayer2.Player; member=PlayPause

The sender is gsd-media-keys:

$ busctl --user | grep 1.78
:1.78                                           3492 gsd-media-keys  tanty :1.78         user@1000.service -       -
org.gnome.SettingsDaemon.MediaKeys              3492 gsd-media-keys  tanty :1.78         user@1000.service -       -

Oddly enough, this happens more often when using some wireless
headphones (no bluetooth, but with a proprietary USB dongle
transmitter) and I'm far from the computer.

#1071717#10
Date:
2024-05-24 08:52:54 UTC
From:
To:
This is expected to happen if your headphones have a play/pause button,
their Linux kernel driver maps it as a partial keyboard, and the
headphones send the keycode for a play/pause multimedia key
(XF86AudioPlay).

Typically wireless headphones have 3 buttons which are mapped as
a partial keyboard with play/pause, volume up and volume down keys
(internally XF86AudioPlay, XF86AudioRaiseVolume, XF86AudioLowerVolume).

Depending on how your USB dongle works, it might identify itself as a
generic USB keyboard with these keys and others, in which case it would
be indistinguishable from a real keyboard; or it might identify itself
as a more specific device.

It sends MPRIS PlayPause in response to a keyboard event reporting either
your configured key combination, or the dedicated play/pause multimedia key.

gsd-media-keys intentionally recognises the multimedia key even if a
different keyboard key combination has also been configured, because that's
necessary to make typical Bluetooth headphones work as expected.

This sounds as though your USB dongle might be falsely reporting button
presses when the wireless link to the headphones is at the limits of its
range. If that's the case, then there is nothing that gsd-media-keys
will be able to do about this: it can't tell the difference between a
real button press and a spurious one.

A workaround would be to use dconf-editor or gsettings(1) to unconfigure
the static/hard-coded binding for XF86AudioPlay:

    gsettings set org.gnome.settings-daemon.plugins.media-keys play-static '[]'

Please try that and see whether it avoids this problem?

This will prevent correctly-functioning wireless headphones
(e.g. Bluetooth) from controlling play/pause as they are intended to be
able to do, and will also prevent recognition of a dedicated play/pause
key that is available on some USB or wireless keyboards, so only use
that workaround long-term if that is acceptable collateral damage. You
can undo the workaround if it is no longer desirable with:

    gsettings reset org.gnome.settings-daemon.plugins.media-keys play-static

I don't think the various -static bindings are configurable in the UI,
because reconfiguring them breaks intended functionality of hardware
that is working correctly.

    smcv

#1071717#15
Date:
2024-05-29 12:19:28 UTC
From:
To:
Hi Simon,

Thanks for the thorough explanation.

I was already considering this and it may be as you say, but I wonder
why the headphone would be sending "false" key presses randomly and,
more often, when I'm far from the dongle receiver.

I'll check on a way to log the key presses when using the headphones so
I can conclude that this is the case or not.

Thanks again!