I have some Bluetooth earbuds (Edifier TWS1 Pro) connected to a laptop running Debian. (edit: with Cinnamon)

When I tap either the left or right earbud, playback pauses/resumes. This is very annoying because I hardly ever use that functionality intentionally, but I trigger it many times a day by accident as I adjust the earbuds in my ears.

I'd like to disable the Bluetooth controls or instruct VLC and mplayer to ignore the play/pause signal from the earbuds.

For VLC there's the workaround of making sure the VLC window doesn't have focus.

I have searched and found https://superuser.com/questions/1761350/how-to-disable-inline-headphone-controls-on-windows-10-11 for Windows (and no usable answer), https://answers.microsoft.com/en-us/msteams/forum/all/any-way-to-disable-headset-control/ffef7d41-d72c-482b-898b-ed1858c03562 (similar), https://askubuntu.com/questions/1236049/how-do-i-disable-headphone-controls (unanswered) and dozens of threads about various BT connection issues.

I've considered trying to open the earbuds and disconnecting the buttons permanently, but these things aren't easy to open without damage and the buttons are useful when pairing. I've also considered making some kind of cover so I can't accidentally touch the buttons, but it probably wouldn't look great.

I know some earbuds have physical buttons instead of touch buttons. I prefer those, but the vast majority (including the ones I have) unfortunately uses touch despite physical buttons costing less than $0.01. I also know the actual button configuration depends on the brand. IIRC, QCY uses double tap for play/resume and binds nothing to single tap, but none of their earbuds achieve 10 hours playback time. Besides, this is a software problem, so a software solution is preferable over purchasing new hardware.

Edit: After following the link from JoSSte's comment I ran xmodmap -pke and found keycode 172 = XF86AudioPlay XF86AudioPause XF86AudioPlay XF86AudioPause. After entering xmodmap -e 'keycode 172 = ' tapping my earbuds no longer results in pausing/resuming! This change won't persist with a reboot, but I can probably figure that out. And I'm already happy to have any control over this at all.

Edit 2: While this technically works, sadly I found out that keycode 172 gets re-registered on a regular basis. I'm unsure what triggers it, but at least putting the earbuds in the charger and taking them out again does. But it also seems to happen randomly. The obvious solution would be to run xmodmap -e 'keycode 172 = ' every 15 seconds or so, but this won't fly as that command causes the screen to freeze for a few seconds. So this question remains open.

Edit 3: I created a little shell script to automate this:

while [[ 1 ]]
    badkey=$(xmodmap -pke | grep -c "keycode 172 = XF86AudioPlay XF86AudioPause")
    if [[ $badkey == 1 ]]
        xmodmap -e 'keycode 172 = '
    sleep 5

This needs to be running all the time. In the actual script I also play a sound when it finds keycode 172 has been populated again. Through this I found keycode 172 is reactivated whenever my Bluetooth mouse reconnects as I touch it after it entered standby due to inactivity. Even if the earbuds are not connected. And despite my mouse having no multimedia keys.

Edit 4 (Oct 3, 2023):

I don't think this is the answer, but YMMV maybe.

  • Enter dconf-editor in a terminal window.
  • Navigate to /org/cinnamon/desktop/keybindings/media-keys.
  • Locate any entries that include XF86AudioPlay and/or XF86AudioPause in their values.
  • Go through all of those, disable "Use default value" and enter [] for its custom value.
  • Reboot the computer?

This is specifically for the Cinnamon desktop environment. I also noticed the existence of /org/gnome/settings-daemon/plugins/media-keys/ with similar values.

I'm unsure if it worked now: VLC no longer pauses/resumes when I tap the earbuds, but mplayer still does. I also messed around with the settings in VLC (tools>preferences>show all>interface>hotkeys settings) and I'm unsure now what worked for VLC, but I think it only worked after a reboot.

  • Which UI are you running? If gnome maybe this answer, where you change the keyboard configuration , is helpful: askubuntu.com/a/1200910/366957
    – JoSSte
    Sep 20, 2023 at 14:16
  • 1
    Thanks, I'm using Cinnamon. Following your link I ran xmodmap -pke and found keycode 172 = XF86AudioPlay XF86AudioPause XF86AudioPlay XF86AudioPause. After entering xmodmap -e 'keycode 172 = ' tapping my earbuds no longer results in pausing/resuming!
    – AlexisAV
    Sep 20, 2023 at 14:57
  • Many times formulating what to search for is the actual issue 😉Many times thecontrol buttons on your bluetooth accessories/keyboards/gadgets for music playback control are the same commands as the multimedia keys on keyboards. I simply searched for "disable multimedia keys gnome" and found that answer.
    – JoSSte
    Sep 20, 2023 at 18:31
  • 1
    @JoSSte indeed. Unfortunately, and presumably unlike multimedia keys on keyboards, the solution doesn't work as well as I thought. Keycode 172 gets re-registered on a regular basis. It happens when the earbuds connect, but also seems to happen while they're connected. I'm unsure what the trigger is. Blindly running the xmodmap command isn't an option as that freezes the screen for a few seconds.
    – AlexisAV
    Sep 21, 2023 at 13:54

2 Answers 2


For VLC either the dconf-editor steps (described in "edit 4" of my question) or adjusting the hotkeys in tools>preferences>show all>interface>hotkeys settings within VLC did the trick.

For mplayer I created a file ~/.mplayer/input.conf with the contents PLAY osd_show_text "Ignored multimedia key". PLAY was the right key for me, but run mplayer -input keylist for all available key names. (http://www.mplayerhq.hu/DOCS/HTML/en/control.html) The command I used overlays the text "Ignored multimedia key" onscreen when playing video or does nothing when there is no video window. Run mplayer -input cmdlist for all available commands. See http://www.mplayerhq.hu/DOCS/tech/slave.txt for details on what those commands do.


This works for me.

# cat /etc/udev/rules.d/logi-g935.rules
KERNEL=="controlC[0-9]*", SUBSYSTEM=="sound", ACTION=="add", ATTRS{id}=="Headset", RUN+="/usr/bin/su tim -c /opt/udev_scripts/g935_hook.sh"

# cat /opt/udev_scripts/g935_hook.sh
/opt/udev_scripts/disable-g935-buttons.sh &

# cat /opt/udev_scripts/disable-g935-buttons.sh
cd /home/tim

export DISPLAY=:0
export XAUTHORITY=/home/tim/.Xauthority
export XDG_RUNTIME_DIR=/run/user/1000
export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus

sleep 0.3

xinput disable "Logitech G935 Gaming Headset"

The directory change and some of the exports may not be required. I needed all of them to deal with pactl a while back.

I'm not sure how the hook.sh interacts with udev. If the second script takes too long, it will still be killed. It's supposed to make sure xinput is aware of the headset when executed. I'm neither sure if you really need it when you trigger the rule using the sound subsystem like I do. May or may not be a race condition, i won't test that for now. Those things usually don't last forever anyway, but I'll read reports on this.

  • don't forget to chmod +x ... in /opt/udev_scripts like I do when creating files :)
    – TimBlo
    Mar 18 at 0:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .