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.

Rant coming your way..!

I use a frighteningly large number of online services/applications/whateveryoumaycallthem. Gmail, Google Reader, Google Calendar, Google Docs, Dropbox, Remember the Milk, GooSync, Twitter, WordPress, Delicious and that’s probably not even all of them.

The big sinner is obviously Google. Even though I’m reluctant to admit it, they make some darn great software – too great to not use. The same is true for the other services. One innovative, beautiful web application after another.

What’s scary is that I’m so dependent on them. I get chills from just thinking about something crucial happening to Google.

But I guess Google has reach a size where reliability will never be a problem. Too many users depend on them and hopefully they are aware enough of their responsibility to not just pull the plug.

The next stage after this concern about Google just pulling the plug is the monopoly concern. Just like Microsoft took over the world through your personal computer, Google is doing it through the web. I guess it can be seen as an advantage that everything is streamlined and so on but I choose to be worried. If Google went down, the world would really just halt. Communication lost, appointments forgot, tasks undone, data gone, etc.. Disaster!

Accepting the fact that the evolution is inevitable and that I’m a sucker for Google and other web services takes me to my next subject.

Operating systems (OSs) are depreciating. I’ve said it before and I’ll say it again:

Give me a browser and a text editor and I’m ready to take over the world myself!

90 percent give or take of the time I spend on a computer I’m either in Firefox or some obscure text editor. True story.

I’m not saying that OSs are becoming unnecessary, just irrelevant for everyday work. Any modern OS can fire up a browser and a text editor, and if that’s more or less all that’s needed on a daily basis, maybe we need to rethink the entire design of modern OSs. Simplify rather than complicate them if you will.

As point of departure though, I can’t fully support this evolvement because of the statements first in this post. I’m simply not comfortable with the thought of people gullibly putting their personal data in the hands of someone/everyone else.

I would like, however, to draw a final perspective that’s not just relevant somewhere in the future, but also today. On any computer you use for regular tasks like mailing, browsing, documenting, if the OS is irrelevant, why not install an open source one for free? It’s just plain ludicrous to pay for an OS you’re not directly using. You use the applications you’re installing on the OS, and any OS can manage most of those applications, also open source ones.

If you’ve read this far, largely agreed with my points, not quite understood this open source thingy, but – sensible as you are – noted that you can get an operating system for free and free yourself from the monopoly that is Microsoft, you’re probably wondering where. My best answer to that question is www.ubuntu.com. Here you can download a free and open source operating system called Ubuntu built upon the Linux kernel. Highly recommendable.

Rant… over…

Today I went to the Free and Open Source Software (FOSS) conference in Aalborg. It concerned two main topics, secure programming and real-time/embedded systems. Here are some highlights and reasons I was glad that I went. While it was incredibly relevant for my education, I didn’t find the real-time/embedded part very interesting. It was plain boring, so I won’t comment on that.

Development tools

During the day several helpful tools for software development were introduced and recommended. That included tools for bug tracking, documentation, etc. Especially interesting ones were doxygen, doxygen-gui, graphviz, valgrind and splint.

Git eye-opener

A guy named Esben Haabendal talked about git through practical examples. As opposed to some documentation about git I’ve read online which I found a bit arbitrary and complex, this talk was really an eye-opener for me. Even though the presentation itself wasn’t particularly good, the talk provided an introduction to some terminology within git, basic commands/operations and more importantly the context in which they are used. Also the brief explanation of distributed version control systems and how they implement various workflow models was very interesting. I can definitely see why git outrules subversion or other centralized version control systems in larger projects.

The OpenBSD guys

There were two german OpenBSD developers, Henning Brauer and Sven Dehmlow, present. Two funny but also extremely OpenBSD religious characters. I really enjoyed their presentation about code security and rightness. Particularly, I found the part about chroot and privilege seperation interesting. But also their slides. They were different with colors, beers as progressbars, legos as flowchart, etc.

Book recommendations

Henrik Lund Kramshøj talked about security tools, mainly for programming also. His talk was alright and he recommended a couple of books. They were:

• Secure Coding: Principles & Practices – Principles and Practices by Mark G. Graff and Kenneth R. Van Wyk
• 19 Deadly Sins Of Software Security – Programming Flaws And How To Fix Them by Michael Howard and David LeBlanc

Wrapping up

There are several other things from the conference on my list that I plan to look more into, so I guess in all it was 200 dkr well spent. The food there was also much better than expected, but I was disappointed that we didn’t get a t-shirt.

To zoom out a bit, the conference reminded me what great community exists around the open source idea. Once again I’m really motivated to contribute.

Finally, all talks were video recorded, so they should become available online together with slides etc. at some point. The talks from last year’s conference are available at http://mirrors.dotsrc.org/blivklogere/foss_aalborg/2008/.

Back in my Arch Linux exclusive days I got really happy with the window manager Awesome. It’s lightweight, tiling and actually arranging your windows as opposed to metacity/compiz (default WMs on Gnome).

Tonight, I decided to install Awesome on Ubuntu (my current distro). If you’re interested in doing this too, please read on.

I found a great walk-through for doing it. The links, however, were broken so now, I want to share the right ones with you here.

Getting Awesome

1. Right now, the current release of Awesome is not in the official Ubuntu repos, so we have to pay a visit to Debian’s packagefinder. The Awesome packages can be found at http://packages.debian.org/search?keywords=awesome.
2. Choose the package from unstable to get the latest release.
3. Choose your architecture at the bottom of the page. It’s probably i386.
4. Finally, choose a mirror and download the deb package.

Getting dependencies

The Awesome package won’t just install, at least if you have a regular Ubuntu setup similar to mine. It will however complain about some dependencies which are not installed or just not up-to-date. Luckily, this is easy to fix. What I did was the following:

1. Go to http://ftp.uk.debian.org/debian/pool/main/x/xcb-util/.
2. Download and install the packages with filenames similar to those on the picture from my desktop below.

UPDATE: On another computer I had to fire up Synaptic and also install libev3 with it’s dependencies.

Prepare for Awesome

1. Run “gconf-editor” and go to

   desktop > gnome > session > required_components

2. Delete the value for “panel” and change the value of windowmanager from “gnome-wm” or “compiz” to “awesome”.

Install Awesome

1. Well, just run the Awesome package you downloaded before. If it still complains about dependencies, my quess is that they’re also in the directory you got the other ones from. So really, just download the ones you need.
2. Also, remember to run the two commands below to get a configuration file.

   mkdir ~/.config/awesomecp /etc/xdg/awesome/rc.lua ~/.config/awesome/rc.lua

3. Finally, do the Ctrl+Alt+Backspace to restart X and a fine, fine and Awesome desktop will hopefully greet you.

Wrapping up

I haven’t had the time to tweak Awesome yet but my fresh install looks like this screenshot.

Be sure to check out Dave’s post which this post is entirely based on.

Enjoy!

Time for a good ol’ rant. Around Ubuntu, XP and Vista users I get way too many questions about why the crap I use Arch Linux. Why use it when I can get a perfectly fine operating system without working for it? The short explanation is, well it’s not perfectly fine and Arch just feels good. Strangely this “argument” doesn’t seem to satisfy the question, especially not when I sometimes sit in dirt to my knees with Arch and people gloatingly start offering me Ubuntu CDs. Urgh that’s annoying. I mean, don’t blame the operating system for my incompetence. Anyway, I’m sick of defending it. Mainly because I don’t have “the long explanation” nor that many arguments. My best one though – besides that it just feels good – concerns the peripheral of the Arch Philosophy, and that is what I’m going to discuss in this post.

To get things started, let’s begin with a few wise words from the Arch Wiki. Arch follows the KISS (Keep It Simple Stupid) philosophy, meaning http://wiki.archlinux.org/index.php/The_Arch_Way:

Arch Linux defines simplicity as a lightweight base structure without unnecessary additions, modifications, or complications, that allows an individual user to shape the system according to their own needs. In short; an elegant, minimalist approach.

And as the Arch wiki so truthfully explains the consequence of this http://wiki.archlinux.org/index.php/Arch_Linux:

(…) Rather than tearing out unneeded and unwanted packages, Arch offers the power user the ability to build up from a minimal foundation without any defaults chosen for them. It is the user who decides what Arch Linux will be.

I know these two quotes are written by idealistic and incarnated Arch founders with only brainwash in their minds. After a year however on the highway of Arch I can only support it and say that it is indeed true.

Obvious proof shows itself in the size of the iso image of Arch on ~270MB. Compared to Ubuntu, the size of Arch is only one third of it (actually it has grown about a 100 MB since I started using it, which I don’t know what to think of. Guess it’s ok since they’ve actually included space invaders on the install CD).

But to grap hold on the philosophy and quotes again, an important term is bloat. Bloat in the software sense is when the software takes up “unnecessary” amounts of memory, CPU, etc. If we talk operating systems, bloat is often refered to as too much pre-installed software. Software that the developers pre-install because they think you’ll like it, and also because of the developer’s desperate efforts to make the software more user friendly. Sadly they overdo it too often.

Ubuntu is a victim of this phenomenon. Ubuntu is heavily bloated compared to Arch Linux. It’s not necessarily a bad thing though. The Linux community needs these kinds of distributions in order to attract new members who would be lost without pre-installed applications for browsing, mailing, text editing, instant messaging, etc. Not only wouldn’t they know which applications to look for, they wouldn’t even know how to install them.

Bloated distributions are crucial to the quest of spreading Linux. It lets you get comfortable with the environment and the applications in your own pace, and when you feel like it or the pre-installed software isn’t sufficient, you can advance yourself to install new software, configuring themes, look at compiz, etc. Eventually you get annoyed by little things like the network manager, compiz breakdowns, incompatibility, and you procede to learning the lonely terminal, driver installation, text file configuring and eventually kernel recompiling. When you get to this point, I guess you can consider yourself an experienced user, having fiddled around with the above, X, desktop environments, window managers and different options for your main applications. Most importantly the experienced user have hopefully gained insight on the fact that Ubuntu is… Wait for it… BLOATED!

This is where Arch Linux joins the party. Exactly for the reasons in the quotes above, the experienced Linux user is best off with a do-it-yourself and keep-it-simple distribution. You’ll want to get in complete control of your operating system by installing this kind of distribution and really get under the hood of Linux. The pieces of knowledge you acquired in Ubuntu get connected in Arch (just to keep using these two as examples). You get to understand how things work simply because you have to do every single thing yourself. Nothing works out of the box in Arch and I’m not afraid to admit it. My point is this: Considering the quality of a piece software (especially operating systems) it can only go two ways, up or down, and in this case the one DOES exclude the other. The quality of bloated software that “just works” out of the box, is user friendly, etc. can only go down. The quality of an operating system where you start from scratch and build up you system brick by brick can only go up. It can only get better and only you choose what kind of house you want to build.

Sure the learning curve is steeper, but once you get your DE/WM of choice, network, sound, graphics and other stuff you need working, you’re left with a stabile, clean system that only does what you need. You can always expand it – the point is that it will never do more than you ask it to. And this will inevitably reduce the errors and mysteries Ubuntu will challenge you with. Your use of your computer’s ressources are also reduced which can be a huge benefit on e.g. laptops.

Arch is indeed very flexible and the postulation, that it’s the user who decides what Arch will be, I can only support by telling that I currently use Arch on every single one of my four primary computers, that is two laptops, my desktop shuttle PC and even my server which both handles SSH, FTP, mail, Apache, MySQL, PHP and so on. Everything runs flawlessly. Your biggest problems with Arch will probably occur when you first install it on some new hardware you’re not entirely familiar with. After that, I’ve found that I rarely have problems.

I guess you’re wondering: “So, where’s Windows in all this?” You probably know that it normally turns my stomach to mention that sinful name on my blog. But in this case, Windows actually isn’t that bad. I won’t even start on Vista, but looking at the size of today’s computers, I don’t think that a basic XP install can be considered bloated. Without having insight to the internals of XP, I’m not afraid to say that it’s actually quite well proportioned after a fresh install. You’re obviously not given a lot of choice during the installation, but that’s an acceptable consequence of the user friendly, relatively clean install you get. Only a few things (like that terrible IE browser) besides the majority of your hardware are installed.

Finally, I know I can’t talk for everyone, and I admit that it’s an individual choice whether you place yourself at the bottom or the top of this bloat scale where heavily bloated software belongs at the top. To tell the truth, I haven’t found a Linux middle ground like I think XP is. I think new users are or should be forced to start at a high level of bloat in Linux. Else I fear that they’ll just get scared and run back to where they came from. But I have to say that I feel sorry for experienced Linux users who don’t use Arch or something similar. Maybe they just don’t care about ressources on or who has the control of their system. But they also don’t know what they’re missing, except maybe a lot of work in the beginning.

Rant over.