You are not logged in.
Let's hope someone has a different idea soon. Sorry you ran into this.
Thanks. I have it ion 2 other forums. Thank you for trying and everything.
I am command line illiterate. I use MX-21.3 Linux.
Offline
You have it on ours, for instance: are you actually running MX Linux?
MX-23 (based on Debian Stable) with our flagship Xfce 4.18.
Offline
You have it on ours, for instance: are you actually running MX Linux?
Yes, I am running MX-18.2 Linux.
I am command line illiterate. I use MX-21.3 Linux.
Offline
Just curious, this is marked solved. Why?
This got me looking at vms where it doesn't work. However the host does not pass the key....
Further looking, the 'media' buttons do work on the host without any entries in >Settings Manager>Keyboard>Application Shortcuts
Where might the key bindings be stored then?
Also, in making some buttons for the capture I use a different cli
amixer -D pulse sset Master toggle
Does not work
amixer set Master toggle
Does
Of course, I use Capture instead of Master for those buttons
Offline
Problem:
XFCE volume keys (Up, Down, Mute) were not working correctly. Symptoms evolved through troubleshooting but included:
No response at all.
Volume OSD showing but volume not changing.
Volume changing but without key repeat, or with very slow repeat.
xfsettingsd logging "Failed to grab keycode" errors for volume keys.
Troubleshooting Steps & Discoveries:
Initial checks for PulseAudio status, pactl commands working directly.
Attempts to use acpid rules: Worked for single presses but no repeat, and involved issues with pactl syntax and permissions.
Attempts to use XFCE custom keyboard shortcuts with pactl and amixer: Showed OSD but often didn't change volume reliably or lacked repeat.
Key insight: xfsettingsd (XFCE's settings daemon) was consistently failing to "grab" the keycodes for volume up/down, preventing xfce4-pulseaudio-plugin from handling them natively with repeat.
The conflict was eventually traced to xbindkeys being installed and having an active configuration in ~/.xbindkeysrc that bound XF86AudioRaiseVolume, XF86AudioLowerVolume, and XF86AudioMute to a custom script (jack-volume-direct.sh). This xbindkeys grab took precedence over xfsettingsd.
Solution:
Disable xbindkeys's conflicting bindings:
Commented out the relevant lines for XF86AudioRaiseVolume, XF86AudioLowerVolume, and XF86AudioMute in ~/.xbindkeysrc.
Killed the running xbindkeys process (e.g., killall xbindkeys).
(Optional but recommended for long-term fix: prevent xbindkeys from autostarting if not needed for other critical functions, e.g., by adding Hidden=true to /etc/xdg/autostart/xbindkeys.desktop copied to ~/.config/autostart/, or by uninstalling xbindkeys).
Ensure acpid is not interfering:
Disabled custom acpid event rules for volume up, down, and mute (e.g., by renaming /etc/acpi/events/vol-up to /etc/acpi/events/vol-up.disabled, etc.) and restarted acpid.
Rely on XFCE's native handling:
Removed any custom XFCE keyboard shortcuts for volume control (in Settings Manager -> Keyboard -> Application Shortcuts).
Ensured xfce4-pulseaudio-plugin was present in the panel and its "Enable multimedia shortcuts" option (in its Properties) was checked.
Restarted xfsettingsd (e.g., killall xfsettingsd; xfsettingsd --daemon) and xfce4-panel -r to ensure a clean state.
Adjust X11 Keyboard Repeat Rate:
The default X11 key repeat rate was too slow. Adjusted using xset r rate [delay_ms] [rate_cps] (e.g., xset r rate 200 50).
To make this permanent, added the xset r rate ... command to XFCE's autostart applications (Settings Manager -> Session and Startup -> Application Autostart).
This allowed xfsettingsd to correctly grab the media keys, enabling xfce4-pulseaudio-plugin to handle them natively, providing smooth key repeat and OSD integration for PulseAudio volume control.
Offline
[ Generated in 0.025 seconds, 7 queries executed - Memory usage: 537.81 KiB (Peak: 538.66 KiB) ]