Last change 09.04.2013
Deutsche Version

multimedia keys


Starting point

Our starting point is a notebook Dell Inspiron 9400 ("portable cinema") running Opensuse 10.1 without any troubles. One of the few minor annoyances were those seven so-called multimedia keys at the front of it.(see foto).

multimedia keys at the front of the case
Dell Inspiron 9400 front view. At time of delivery (Feb 2006) there was no Linux distribution supporting them out-of-the-box
Using a well known operating system from Redmond ("recommended by the manufacturer") it is sufficient to install a driver from the bunch of CDs you get presented with, and soon you are able to use an audio-player through those keys. After installing Opensuse 10.1 (or any other Linux-Distribution at that time) all you get is a nice blue-violet light behind those buttons - that's it.

I'm using KDE version 3.5 and my favourite mp3 player is amarok. The target is to control amarok via the multimedia keys.

What to do?

There are several steps necessary to achive that goal:

  1. We need the codes those keys send when pressed
  2. We have to name that codes to tell them to X11
  3. For each key KDE must establish a mapping (KDE key mapping) from the event to an appropriate action

Key codes

xev window
the program xev lists all X events - like a pressed or released key

Our friend is xev. This program is very useful since it lists all X11 events: pressing /releasing of a key on the keyboard, mouse events, etc. Its output is a little bit confusing at first glance, but the following script will help you to focus on the important information:

xev | awk '
   {split($0,f,/[()]/);
    if (f[2]!~/^keysym/) next;
    c=split(f[2],g,", ");
    print $4,g[2]}'

After calling that script you press all buttons you want to identify. If you do not see any output, move the cursor into the black framed square.

Output should look like this:

162 None
164 None
...

Assigning names

Now we can assign symbolic names to the buttons. X11 has appropriate names for the 7 multimedia keys of the Inspiron 9400 (and most other laptops), like XF86AudioPlay for then "Play" button. The assignment usually takes place via the file ~/.Xmodmap. For my Inspiron 9400 it looks like that:

  
keycode 162 = XF86AudioPlay
keycode 164 = XF86AudioStop
keycode 144 = XF86AudioPrev
keycode 153 = XF86AudioNext
keycode 176 = XF86AudioRaiseVolume
keycode 174 = XF86AudioLowerVolume
keycode 160 = XF86AudioMute

For testing purpose you can call it like this:

xmodmap ~/.Xmodmap
. If you call xev again you should see the symbolic names whe you press one of our multimedia buttons.

X11 calls ~/.Xmodmap at startup, so the mapping will be in effect. But there is still no action attached to button event.

KDE mapping

communication between KDE and applications works via DCOP: Desktop COmmunication Protocol. That way KDE exchanges messages with its applications. In our case we want KDE to translate a multimedia key into the correlated action in amarok.

Using kcontrol, the KDE control center we persuade KDE to hand over key events as DCOP-commands to other programs. On Novell Suse (10.1) you find it under Personal settings. In older versions you would look for Kontrollcenter.

In the submenu Regional & Accessability/Input Actions click on one entry within the window titled Actions. Now there is an entry New Action at the bottom. Click that one. It should look now like the picture below.

Kontrollcenter
KDE Kontrollcenter with already assigned keys; DCOP actions are on the right side

  1. Under General you enter the name of the key in the field titled Action name, then in the window below named Action type you must select Keyboard Shortcut -> DCOP Call (simple).
  2. Now you must switch over to Keyboard Shortcut. Click the field titled "None" and a window titles "Configure Shortcut - Personal Settings" will appear. Click into the empty titled "Primary Shortcut" and press the key you want to assign an action to. The symbolic name of that key should appear.
  3. Under DCOP Call Settings you can enter the name of the application (e.g. "amarok"), the name of the object (e.g. "player") and the name of the action ("next" or "prev" or whatever).
You can test the action by clicking Try, finally press Apply.

It works, but ...

There are some minor flaws in the concept.

  1. For reasons unknown, KDE does not start xmodmap (it should do it!). I just entered a start script into directory ~/.kde/Autostart. Zero points for elegance, but it does the trick.

  2. Controlling speaker volume via amarok brings a disadvantage: If Amarok is not running DCOP commands are not working - nobody is listening!. Additionally is it difficult to find a good balance between amarok's volume and system volume which get mixed together. Setting system volume to 80% makes good control via amaraok, but system sounds are unbearable loud. Setting system to a lower volume gives you too less control via amarok. A better solution is to control volume via kmix, the best one is to use amixer. The latter is not KDE-aware (not even X11), so wee need a wrapper script to call it:

    #!/bin/bash
    
    if [ $# = 0 ] ; then
       ADD="+1"
    else
       ADD="$1";
       fi
    
    NEWVAL=$(amixer -c 0 get Master | \
       awk '$1=="Front"&&$2~/Left|Right/ {
    		val[c++]=$4; next}
            END	{ printf "%d,%d\n",
    		    val[0]'$ADD',val[1]'$ADD'}')
    amixer -c 0 sset Master 0 $NEWVAL
    

    To use it, select keyboard Shortcut -> Command/URL (simple) as Action type and enter the name of the script under Command/URL Settings as Command to execute with the additional parameters +1 for volume up and -1 for volume down.

  3. Some programs like screen savers will catch all incoming events. So when your monitor is locked (the automatic response for shutting the lid of a laptop computer) you wont be able to use the multimedia keys.