anderstornvig.dk

By default no “extra” keys have ever worked on my Arch Linux installs. Today I made an effort for solving that and I succeeded primarily on the basis of this forum thread, this blog post, this article and Extra Keyboard Keys in Xorg on the ArchWiki. The task is simple:

Adjust the output volume on my computer when I press the multimedia keys (play, mute, volume up, volume down) on my keyboard.

How key presses are registered and handled (simplified)

So what happens on the inside when you press the keys on my keyboard? Well, each key press is recognized by the X server as an X event. When an event is registered the X server executes a routine assigned to that specific event. E.g. if the letter “k” is pressed it will simply echo a “k” to the application that is listening for keyboard input. This “application” is usually the window manager running on top of the X server and when the window manager registers the keyboard input it will pass it on to the application which has focus right now. Could be Firefox. Let’s have a small ASCII flowchart to sum up the example. Firefox has focus, runs inside the window manager and the window manager runs on top of the X server.

The user presses the key "k" inside Firefox ->
The X server registers the "k-key-pressed"-event ->
The X server passes the event to the window manager ->
The window manager passes the event to Firefox which has focus ->
The letter "k" is written into the address bar, a textarea, whatever.

Brilliant. Now, what happens if there’s no X server routine assigned to a specific X event? Nothing. This is exactly the reason why the multimedia keys does not work in my X by default on Arch Linux, thus the problem we are going to address in the following. Before that I should say that the problem is not distribution nor window manager related. You’ll encounter it on any installation where the X server is not set up properly or there’s no dummy application taking care of the specific event.

Identify keycodes for multimedia keys
Each key on your keyboard has a keycode assigned within the X server whether there’s a routine assigned for it or not. First we need to find out which keycodes Play, Mute, Volume up and Volume down have. We can do this by running xev inside a terminal instance running in X. You’ll most likely have xev already, if not then install it. When you have it running, press the four keys shortly right after each other. Look for output similar to this:

KeyRelease event, serial 28, synthetic NO, window 0x2800001,
   root 0x253, subw 0x0, time 28502634, (263,0), root:(3169,410),
   state 0x0, keycode 172 (keysym 0x1008ff14, XF86AudioPlay), same_screen YES,
   XLookupString gives 0 bytes:
   XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x2200001,
   root 0x253, subw 0x0, time 21416440, (235,1), root:(3141,411),
   state 0x0, keycode 121 (keysym 0x1008ff12, XF86AudioMute), same_screen YES,
   XLookupString gives 0 bytes:
   XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x2200001,
   root 0x253, subw 0x0, time 21417224, (235,1), root:(3141,411),
   state 0x0, keycode 122 (keysym 0x1008ff11, XF86AudioLowerVolume), same_screen YES,
   XLookupString gives 0 bytes:
   XFilterEvent returns: False

KeyRelease event, serial 28, synthetic NO, window 0x2200001,
   root 0x253, subw 0x0, time 21417968, (235,1), root:(3141,411),
   state 0x0, keycode 123 (keysym 0x1008ff13, XF86AudioRaiseVolume), same_screen YES,
   XLookupString gives 0 bytes:
   XFilterEvent returns: False

These are the outputs of the four key presses Play, Mute, Volume up and Volume down and I’ve marked the parts relevant to us bold.

Map keycodes to routines for multimedia control in X
Routines for volume adjustments in X is defined by the “labels” XF86Audio*. xmodmap is a small utility that will bind any of your keys to labels by referencing them to keycodes. The procedure for setting it up is simple. Install it if necessary, then create a file .Xmodmap in your home directory and put the keycodes and labels in it. In my case (and probably also yours) the content will look like this.

keycode 172 = XF86AudioPlay
keycode 121 = XF86AudioMute
keycode 122 = XF86AudioLowerVolume
keycode 123 = XF86AudioRaiseVolume

Run

xmodmap ~/.Xmodmap

to activate it in the current session. To make it permanently start when you start X, put the command in your  ~/.xinitrc also.

Bind volume multimedia keys
All of the four keys actually works now when multimedia applications like mplayer, VLC and Rhythmbox have focus in your window manager. But the volume keys currently do not control the ALSA sound system directly (I assume that’s what your using for sound). By adjusting the volume directly in ALSA rather than your player you adjust it globally.

ALSA can be controlled by amixer (you already have amixer if you have ALSA installed), so what we want to do is bind an amixer shell command to our volume keys.

This can be done in many ways and I’m going to share three of them with you here. Two window manager (Xmonad, Awesome) specific ways and one standalone utility (xbindkeys) for doing it. The thing is, if you have key binding support in your window manager already there’s no reason to use a standalone utility for it, but if your window manager does not support or handle key bindings very well, it’s nice to have an alternative.

Xmonad window manager

The Xmonad window manager provides key binding support configurable in the Haskell configuration file ~/.xmonad/xmonad.hs. I’m going to assume that you have one of these already and just tell you what you need to add. Xmonad does not have key names for the ones we’re going to add so we have to refer to their hex value which can be found in the file /usr/share/X11/XKeysymDB. Find the three relevant volume labels and remember their value (yours are most likely identical to mine). Now, add them to the key bindings section in your Xmonad config file. I’ve added the following to my config file.

-- Alsa keyboard control
-- XF86AudioMute
, ((0 , 0x1008ff12), spawn "amixer -q set PCM toggle")
-- XF86AudioLowerVolume
, ((0 , 0x1008ff11), spawn "amixer -q set PCM 2- unmute")
-- XF86AudioRaiseVolume
, ((0 , 0x1008ff13), spawn "amixer -q set PCM 2+  unmute")

If you want you can safely change the PCM channel to ie. Master and/or maybe the lower/raise values. Reload the config file by pressing Mod+q.

Awesome window manager

Accoring to this thread, the following three key bindings should work. Add them to your ~/.config/awesome/rc.lua configuration file.

keybinding({}, "#122", function () awful.util.spawn("amixer -q sset PCM 2dB-") end):add()
keybinding({}, "#123", function () awful.util.spawn("amixer -q sset PCM 2dB+") end):add()
keybinding({}, "XF86AudioMute", function () awful.util.spawn("amixer -q sset Master toggle") end):add()

Again, feel free to change PCM and/or the lower/raise values. I haven’t tried that method myself but they look easier than what I had luck on my laptop in my Awesome days. I used these lines my Awesome config file.

table.insert(globalkeys, key({ }, "XF86AudioRaiseVolume", function () volume("up", tb_volume) end))
table.insert(globalkeys, key({ }, "XF86AudioLowerVolume", function () volume("down", tb_volume) end))
table.insert(globalkeys, key({ }, "XF86AudioMute", function () volume("mute", tb_volume) end))

They assume that you have the volume() function defined somewhere else in the config file. This function is available my Awesome config file.

xbindkeys

In fact, xkeybinds can bind your keycodes directly to your amixer commands, thus skipping the label mumbo jumbo. Very convenient. Another advantage is that it’ll work on any window manager. You only have to install it, refer it to your config file, add it to your ~/.xinitrc and you’re good to go. For now, create the file ~/.xbindkeysrc and put the following in it.

# Vol down
"amixer -q set PCM 2- unmute"
  XF86AudioLowerVolume

# Vol up
"amixer -q set PCM 2+ unmute"
  XF86AudioRaiseVolume

# Vol mute/unmute
"amixer -q set Master toggle"
  XF86AudioMute

I think there’s no reason to explain that, but still, feel free to change PCM and/or the lower/raise values.

Wrapping up

Hopefully you got it working. The same methods can be used to enable other multimedia keys. This article “Enabling the Multimedia Keys on your Keyboard” is very useful for that. Like that article I’d probably recommend the xkeybinds solution in most cases as it is very consistent, feature-full and portable. That said, Xmonad as I use for it now also does a fine job. I’ve had no problems with it, it’s easy and I like the facts that it’s integrated in my window manager. Matter of taste.

Thank you for reading.

After my recent 64-bit install I experienced some instability with X. I narrowed the problem down to: X crashes in a dual monitor setup when I hold down backspace, the arrows, maybe other keys inside any application.

The problem was a little hard to google so I threw the question at the Arch Linux Forum.

It turns out you have to install a patched version of the xorg server. Because I had some trouble figuring out dependencies, etc., here is the procedure I got working:

1. If you don’t have yaourt installed, install it. If you don’t know what yaourt is, it is a wrapper around pacman that allows you to easily install user contributed packages from AUR. So, go ahead and install it.
2. You may want to log of X.
3. Perform the following and final steps. The yaourt command will take a while to execute but keep an eye on it anyway to discover it if any errors occur.

   # pacman -R nvidia xorg-server
   # pacman -S libgl
   # yaourt -S xorg-server-warnaud
   # pacman -R libgl
   # pacman -S nvidia

To you with a similar problem, I hope you will find this helpful.

As the Ubuntu Jaunty fever is slowly easing off, I decided to go back to Arch Linux. I simply miss its purity compared to Ubuntu’s.

Once an Archer, always an Archer!

On the old Ubuntu setup I never quite figured a permanent solution for my dual monitor setup and since I installed the Awesome window manager RC, it has been somewhat buggy. Also, in the meantime I’ve more or less commited to another tiling window manager, Xmonad (more on that in another post), so I was planning to switch from Awesome anyway. Bottom line, time to install Arch Linux.

I won’t bore you with the installation details this time but simply say that almost nothing has changed since my post on Installing Arch Linux with Awesome. Well, maybe except for Xorg and its complications with hal. It’s not an Arch Linux specific exception, but excuse me, what a mess? I digress.

So why bother to write this post? Well, to give you a heads up on the Arch Linux 64-bit installation.

Ever since I got my Shuttle PC December 2007, I’ve not been able to make use of all of the 4GB ram available in it. Only about 3.2GB has been available in the 32-bit operating systems I’ve run. Incredibly annoying, but also a well-known and inevitable limitation. Have a look at the post “Dude, Where’s My 4 Gigabytes of RAM” on Coding Horror.

Thus, to try something new and actually take advantage of what I once paid for, I decided to install Arch64. A brief google told me what advantages and more importantly what implications I should expect.

Advantages:

• 4GB ram obviously
• Slightly better performance (have a look at “Ubuntu 9.04: 32-bit vs 64bit benchmarks” on Tuxradar)

Implications:

• Flash (in pacman: flashplugin) is going to be crap
• Java Runtime Environment (in pacman: jre) is going to be crap
• Buggy multimedia
• Skype, Wine, Virtualbox
• Pacman should have 64-bit architectured versions of most which means not all packages

There’s probably a lot more on both sides. I proceded to install it, every step exactly the same as in a regular install. After that, Xorg, Xmonad, browser, text editors, IM clients, multimedia stuff, libraries, basically everything I use if not daily, then weekly.

Guess what, everything worked flawlessly as if I had installed the 32-bit version. Even pacman managed to find 64-bit architectured builds for every package I installed, not just most. Great! Haven’t tried Skype, Wine or Virtualbox yet but I’ve found multiple guides to and examples on people getting it working so I’m not worried. Also, you should have seen the smile on my face when I first fired up top and saw that I had 4GB ram available. Fantastic!

So to end this post I’ll give you the assurance I was looking in my implications/advantages-google, even though it may not be true in some cases:

For what I use my computer for, there has been no implications, only advantages in installing the 64-bit of Arch Linux. You can safely go ahead and try it out if you feel like it and have the right hardware for it.

I honestly don’t know why I waited.

Feel free to post a comment on your Arch64 experience.