I tried to find an answer to this one on the net, and got only things that got me in the right direction, but not a complete answer. For the sake of documentation, here is how to get KDE to recognize your volume keys (or, for that matter, any other special key). The fact that it doesn't happen automatically is probably a bug in the keyboard layout code. I might file it there. This method works with no special processes running. It works whether kmix is running or not. It causes KDE to display visual feedback to the fact that the volume is changing.
First order of business is finding out what is the keycode for your misfunctioning keys. Run "xev". A new window appears, and any message sent to that window appears in the console that ran xev. Be careful not to move your mouse or press any key other than the ones you want mapped, as the messages form very quickly.
Next, with the xev window active, press the keys you want to map. Your output should look something like this:
KeyPress event, serial 34, synthetic NO, window 0x2a00001,
root 0x13b, subw 0x0, time 61891190, (-690,-222), root:(785,703),
state 0x0, keycode 101 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 34, synthetic NO, window 0x2a00001,
root 0x13b, subw 0x0, time 61891190, (-690,-222), root:(785,703),
state 0x0, keycode 101 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 34, synthetic NO, window 0x2a00001,
root 0x13b, subw 0x0, time 61892564, (-690,-222), root:(785,703),
state 0x0, keycode 212 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 34, synthetic NO, window 0x2a00001,
root 0x13b, subw 0x0, time 61892564, (-690,-222), root:(785,703),
state 0x0, keycode 212 (keysym 0x0, NoSymbol), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
This tells me that the key for reducing the monitor's brightness has a keycode of 101, and for increasing it of 212. Record the keycodes for all keys you are interested in. Also, notice that after the keycode you get, in brackets, "keysym 0x0, NoSymbol". This indicates that the keyboard mapping does not know what this key means. If the key is defined, you output should look something like:
KeyRelease event, serial 35, synthetic NO, window 0x2a00001,
root 0x13b, subw 0x0, time 62033566, (-65,-284), root:(1410,641),
state 0x0, keycode 176 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 35, synthetic NO, window 0x2a00001,
root 0x13b, subw 0x0, time 62035609, (-65,-284), root:(1410,641),
state 0x0, keycode 174 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False
This means that I have already implemented what I'm writing about here, and keycodes 174 and 176 are already mapped to the Audio down and up respectively. If that is what you get, and the symbol indeed matches the key's caption, this guide will not help you (but check out a setting called "global shortcuts" in the program that controls the relevant operation).
Also, if you press the key and nothing happens, this guide is also incapable of helping you. I would recommend switching to the textual console and pressing the key. If you get a message from the kernel saying that an unknown scan code was received, the situation is still salvagable. You can tell the kernel to map the scan code to the right keycode. If junk is displayed then the situation may or may not be salvagable. It might mean that the kernel misunderstands the scan code, but it might also mean (happened to me with a Microsoft PS/2 keyboard connected through a PS/2->USB adapter) that something in the hardware munges the scan code. If nothing at all happens, it is possible that the scan code never reaches the kernel, and then there is very little anyone can do.
The next order of business is to tell KDE to make a map between the key code and the proper key sym. For that, we need a list of valid key symbols. On Debian, you can find this list in /usr/share/X11/XKeysymDB. Find there the right symbol for the key. For the audio keys, these are XF86AudioLowerVolume (volume down), XF86AudioRaiseVolume (volume up) and XF86AudioMute (mute). I'm sure the rest are fairly self explanatory as well (well, not all of them. For example, XF86Display is the key that switches between monitors - not exactly trivial mapping).
Last, we want the KDE startup to make these mappings (which, like I said, probably should go into the PC keyboard definition - if anyone has the volume keys bound to a different keycode, please shout). Create a file called ~/.kde/Autostart/keycodes, which has the following structure:
#!/bin/sh
xmodmap -e 'keycode 174=XF86AudioLowerVolume'
xmodmap -e 'keycode 176=XF86AudioRaiseVolume'
xmodmap -e 'keycode 160=XF86AudioMute'
xmodmap -e 'keycode 212=XF86MonBrightnessUp'
xmodmap -e 'keycode 101=XF86MonBrightnessDown'
I'm sure you get the idea from here as far as other undefined keys are concerned. Don't forget to set the execute flag on the file.
That's it. KDE (and many other window managers) already has pretty decent default handling of the XF86AudioRaiseVolume family of sym codes, so there is nothing further you need to do.
