Here's a method that in theory should work.
If you visit the "Accessibility" tab in System>Preferences>Keyboard then you can enable the "Slow Keys" "Only accept long keypresses" option. Turn the delay all the way down and you basically null the effects of this option. Then go to "Audio Feedback..." and enable "Beep when a key is pressed" under the "Slow Keys" section.
This method SHOULD work. I couldn't get it to work, honestly. I do have the sound-theme-freedesktop sound theme installed and enabled. Perhaps it's a bug with gnome 2.32.0.
These configuration options simply play the system bell. On Ubuntu the system bell does not work when desktop effects are enabled. Turn off desktop effects, or on Ubuntu 11.04 login as "Ubuntu Classic (No effects)", and your system bell should work again.
Ok, found this at https://help.ubuntu.com/community/MultimediaKeys
When you hit a key on your keyboard, the linux kernel generates a raw
scancode for it (if it is assigned). Each scancode can be mapped to a
keycode. This is at kernel level. X has a (quasi) total independent
way of mapping keys: X reads the kernel keycode table at startup, then
maps the keycode to its independent keycode table (it is the same as
the kernel keycodes but different :)). Then each keycode can be mapped
to a keysym, i.e. a string which represent a key or suggest an action.
Thus to have our keys fully functional, they need a kernel
scancode/keycode plus a X keycode/keysym. It may seem weird, but X
developers have their reason to keep a separate keyboard mapping from
the kernel. It is not difficult at all, just a quite tedious
procedure.
So keycodes's are mapped to keysym's, So where are the keysym's? I found and answer from this question: Where do I find a list of all X keysyms these days? Since we are talking about the volume keys it would be found in XF86keysym.h
in the source-code mentioned in the answer.
In that file on my computer I found the following for volume:
#define XF86XK_AudioLowerVolume 0x1008FF11 /* Volume control down */
#define XF86XK_AudioMute 0x1008FF12 /* Mute sound from the system */
#define XF86XK_AudioRaiseVolume 0x1008FF13 /* Volume control up */
Strange... different values from anything else, maybe there are multiple systems for handling keys? http://crunchbang.org/forums/viewtopic.php?id=16656
I am using Xubuntu, and to control the keys, I need to map the actions manually(like this How do I change my keyboard shortcuts in xubuntu?). However the notifications seem independent as if they are picking up on the key-press and acting accordingly, It may mean that other programs in Ubuntu are set up this way, so there is no need to map scripts to the keys.
So I'm quite sure that programs are now picking up on the key (so no scrips to be found).
In Xubuntu I had this problem with Pulse Audio and using custom scripts for changing the volume, It seemed that Pulse was intercepting the Mute key, Mute key mutes Alsa and PulseAudio, but unmutes only Alsa made for interesting workarounds.
Check this out about NotifyOSD https://wiki.ubuntu.com/NotifyOSD#Volume_changes
If you look a These diagrams: https://wiki.ubuntu.com/NotifyOSD#Architecture
Especially this one:
It shows that there is a "hardware keys listener" which receives form DBus or HAL?
It then "retrieves visual element from system" which the sound and brightness icons are in the source of Notify-OSD, and then makes the bubble from there.
This is all crazy confusing, but as far as I understand it (so far):
raw scancode (ex. e016) > keycode (ex. 160) > keysym (ex. XF86AudioMute) > gnome-settings-daemon (ex. volume-up) > DBus signal > hardware-keys-listener for notify-osd (or other program listening)
Best Answer
Run
xev
from a terminal. This will give you a new window.Place your mouse pointer in this window, type some keys and watch for results in the terminal.