The mysterious XF86AudioPlay issue
Summary
A blog post detailing the debugging of a recurring XF86AudioPlay key event in Emacs, traced to a headphone device driver using libinput and evtest.
<p><a href="https://lobste.rs/s/tbizqg/mysterious_xf86audioplay_issue">Comments</a></p>
View Cached Full Text
Cached at: 05/22/26, 10:38 PM
# mikas blog » Blog Archive
Source: [https://michael-prokop.at/blog/2026/05/20/the-mysterious-xf86audioplay-issue/](https://michael-prokop.at/blog/2026/05/20/the-mysterious-xf86audioplay-issue/)
I was getting “<XF86AudioPlay\> is undefined” in the status bar of Emacs displayed every 2\-3 seconds\. Nowhere else I noticed any misbehavior or problems, and also couldn’t find any related log entries\. It didn’t stop, though didn’t want to reboot my system to see whether that would fix the problem, but it was driving me nuts\.
Now, as a starting point I adjusted my sway configuration, to react to the XF86AudioPlay key press event:
```
bindsym XF86AudioPlay exec playerctl play-pause
```
After reloading sway, my music player started to play for 2\-3 seconds, stopped playing, started again, etc\. It wasn’t a Emacs bug, but something indeed seemed to send the XF86AudioPlay key event every 2\-3 seconds\. It wasn’t my USB keyboard or any stuck key on it, as verified also by unplugging it\. So which device was causing this?
libinput from[libinput\-tools](https://packages.debian.org/search?keywords=libinput-tools)to the rescue:
```
% sudo libinput debug-events
[...]
-event12 KEYBOARD_KEY +0.000s KEY_PLAYPAUSE (164) pressed
event12 KEYBOARD_KEY +0.000s KEY_PLAYPAUSE (164) released
event12 KEYBOARD_KEY +2.887s KEY_PLAYPAUSE (164) pressed
event12 KEYBOARD_KEY +2.887s KEY_PLAYPAUSE (164) released
event12 KEYBOARD_KEY +5.773s KEY_PLAYPAUSE (164) pressed
event12 KEYBOARD_KEY +5.774s KEY_PLAYPAUSE (164) released
[...]
```
The \`*event12*\` device was sending this event, what’s behind this?
```
% sudo udevadm info /dev/input/event12
P: /devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input17/event12
M: event12
R: 12
J: c13:76
U: input
D: c 13:76
N: input/event12
L: 0
S: input/by-path/pci-0000:00:1f.3-platform-skl_hda_dsp_generic-event
E: DEVPATH=/devices/pci0000:00/0000:00:1f.3/skl_hda_dsp_generic/sound/card0/input17/event12
E: DEVNAME=/dev/input/event12
E: MAJOR=13
E: MINOR=76
E: SUBSYSTEM=input
E: USEC_INITIALIZED=12468722
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_INPUT_SWITCH=1
E: ID_PATH=pci-0000:00:1f.3-platform-skl_hda_dsp_generic
E: ID_PATH_TAG=pci-0000_00_1f_3-platform-skl_hda_dsp_generic
E: XKBMODEL=pc105
E: XKBLAYOUT=us
E: XKBOPTIONS=lv3:ralt_switch,compose:rctrl
E: BACKSPACE=guess
E: LIBINPUT_DEVICE_GROUP=0/0/0:ALSA
E: DEVLINKS=/dev/input/by-path/pci-0000:00:1f.3-platform-skl_hda_dsp_generic-event
E: TAGS=:power-switch:
E: CURRENT_TAGS=:power-switch:
% sudo udevadm info -a /dev/input/event12 | grep -iE 'kernels|drivers|name'
KERNELS=="input17"
DRIVERS==""
ATTRS{name}=="sof-hda-dsp Headphone"
KERNELS=="card0"
DRIVERS==""
KERNELS=="skl_hda_dsp_generic"
DRIVERS=="skl_hda_dsp_generic"
KERNELS=="0000:00:1f.3"
DRIVERS=="sof-audio-pci-intel-tgl"
KERNELS=="pci0000:00"
DRIVERS==""
```
Behind this event12 is*sof\-hda\-dsp Headphone*, and[evtest](https://packages.debian.org/search?keywords=evtest)confirms that:
```
% sudo evtest
No device specified, trying to scan all of /dev/input/event*
Available devices:
/dev/input/event0: AT Translated Set 2 keyboard
/dev/input/event1: Sleep Button
/dev/input/event10: ThinkPad Extra Buttons
/dev/input/event11: sof-hda-dsp Mic
/dev/input/event12: sof-hda-dsp Headphone
/dev/input/event13: sof-hda-dsp HDMI/DP,pcm=3
/dev/input/event14: sof-hda-dsp HDMI/DP,pcm=4
/dev/input/event15: sof-hda-dsp HDMI/DP,pcm=5
/dev/input/event16: Yubico YubiKey OTP+FIDO+CCID
/dev/input/event17: Apple Inc. Magic Keyboard with Numeric Keypad
/dev/input/event18: Apple Inc. Magic Keyboard with Numeric Keypad
[...]
Select the device event number [0-24]: ^C
```
We can even get further information:
```
% sudo evtest /dev/input/event12
Input driver version is 1.0.1
Input device ID: bus 0x0 vendor 0x0 product 0x0 version 0x0
Input device name: "sof-hda-dsp Headphone"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 114 (KEY_VOLUMEDOWN)
Event code 115 (KEY_VOLUMEUP)
Event code 164 (KEY_PLAYPAUSE)
Event code 582 (KEY_VOICECOMMAND)
Event type 5 (EV_SW)
Event code 2 (SW_HEADPHONE_INSERT) state 0
Properties:
Testing ... (interrupt to exit)
Event: time 1779295060.175766, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 1
Event: time 1779295060.175766, -------------- SYN_REPORT ------------
Event: time 1779295061.951168, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295061.951168, -------------- SYN_REPORT ------------
Event: time 1779295061.951194, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295061.951194, -------------- SYN_REPORT ------------
Event: time 1779295064.548671, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295064.548671, -------------- SYN_REPORT ------------
Event: time 1779295064.548689, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295064.548689, -------------- SYN_REPORT ------------
Event: time 1779295067.437172, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295067.437172, -------------- SYN_REPORT ------------
Event: time 1779295067.437187, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295067.437187, -------------- SYN_REPORT ------------
Event: time 1779295070.323775, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295070.323775, -------------- SYN_REPORT ------------
Event: time 1779295070.323790, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295070.323790, -------------- SYN_REPORT ------------
Event: time 1779295073.200350, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295073.200350, -------------- SYN_REPORT ------------
Event: time 1779295073.200373, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295073.200373, -------------- SYN_REPORT ------------
Event: time 1779295076.076228, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295076.076228, -------------- SYN_REPORT ------------
Event: time 1779295076.076250, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295076.076250, -------------- SYN_REPORT ------------
Event: time 1779295078.961740, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295078.961740, -------------- SYN_REPORT ------------
Event: time 1779295078.961754, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295078.961754, -------------- SYN_REPORT ------------
Event: time 1779295081.850156, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 1
Event: time 1779295081.850156, -------------- SYN_REPORT ------------
Event: time 1779295081.850175, type 1 (EV_KEY), code 164 (KEY_PLAYPAUSE), value 0
Event: time 1779295081.850175, -------------- SYN_REPORT ------------
Event: time 1779295083.306612, type 5 (EV_SW), code 2 (SW_HEADPHONE_INSERT), value 0
Event: time 1779295083.306612, -------------- SYN_REPORT ------------
```
So when I plug in my headphone \(see the \`SW\_HEADPHONE\_INSERT\` event\), the unexpected behavior starts, unplugging stops the problem\. Good\! But what was totally unexpected for me: my headphone, being a Beyerdynamic DT\-990 Pro, does*not*have*any*keys\. 8\-\)
As it turned out, the headphone jack seemed to have been not entirely clean\. The*analog*side of the jack triggers a behavior within the audio codec, where it seems to interpret the fluctuating impedance as a play button of the headset, being pressed, again and again\.
I cleaned the jack of my headphone and my XF86AudioPlay problem is gone, case closed\.
This entry was posted by[mika](https://michael-prokop.at/)on Wednesday, May 20th, 2026 at 19:19 and is filed under[Computer](https://michael-prokop.at/blog/category/computer/),[Debian](https://michael-prokop.at/blog/category/debian/),[English](https://michael-prokop.at/blog/category/english/),[Hardware](https://michael-prokop.at/blog/category/hardware/)\. You can follow any responses to this entry through the[RSS 2\.0](https://michael-prokop.at/blog/2026/05/20/the-mysterious-xf86audioplay-issue/feed/)feed\. Both comments and pings are currently closed\.
Similar Articles
Bug Archeology: Solving a decade-old Swift/C++ mystery (with LLMs)
A developer recounts using LLMs to solve a decade-old bug in a Swift/C++ cross-platform music app, demonstrating how AI can assist in debugging complex issues.
@jedisct1: The epoll uaf
A detailed analysis of a use-after-free vulnerability in the Linux kernel's epoll subsystem, fixed by switching to RCU, and the author's failed attempts at exploiting it on a modern device.
A Vompeccc Case Study: Spotify as Pure ICR in Emacs
A deep-dive case study showing how the author built a Spotify client inside Emacs using the VOMPECCC completion framework, demonstrating modular integration of Consult, Marginalia, and Embark packages.
Mechanical Keyboard Sounds – A listening Museum
The Listening Museum is an interactive web-based curator of 36 mechanical keyboards and switches with sound mappings, allowing users to click keyboards and type on their own to hear the audio samples across different builds and recording conditions. It serves as an educational resource rather than a buying guide, emphasizing how recording methodology affects perceived keyboard sound.
The case of the hang when the user changed keyboard layouts
A debugging story about a Windows program hanging when the user changes keyboard layouts due to a background thread that created a window but wasn't pumping messages. The fix is to either pump messages or destroy the window.