Getting volume keys to work in KDE

[Shachar Shemesh]

Hi all,


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.

That's it. KDE already has pretty decent default handling of the 
XF86AudioRaiseVolume family of sym codes, so there is nothing further 
you need to do.

Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20090312/f37738e3/attachment.html>