The last bit of configuration that my laptop required before I’d call it “usable” with the new window manager was related to the function keys. This doesn’t have anything to do with configuring the awesome window manager directly but it does address a few small configurations necessary to provide some functionality that I was used to having gnome do by default.
Linux has great support for Thinkpads in general and my x61s specifically. With basic power management packages installed and the kernel thinkpad_acpi driver loaded not only did S3 work fine but my Thinkpad function key to put my laptop to sleep worked out of the box! The only keys that didn’t work right out of the box were an easy fix.
Traveling as much as I do I find that I use the manual controls for screen brightness quite a bit. If you’re on a plane often times it’s really nice to be able to dial down the screen brightness to absolutely minimal levels to preserve your battery and your eyes. The gnome-power-manager is the gnome component that takes care of this and it’s simple enough to install. Nothing interesting here except a new found appreciation for how much Gnome does out of the box and why it’s so big.
Volume and Mute
Lastly configuring the volume buttons was a must. If you’re just interested in getting them to work, install the gnome-settings-daemon and add a command to your rc.lua file to run it. I spent a little time getting to the bottom of it and learned a little bit.
Fire up a terminal and run the
xev command to see the keyboard events from each key. A regular keyboard key will generate some output like:
KeyPress event, serial 29, synthetic NO, window 0x1600001, root 0x105, subw 0x0, time 316658902, (470,254), root:(472,689), state 0x0, keycode 24 (keysym 0x71, q), same_screen YES, XLookupString gives 1 bytes: (71) "q" XmbLookupString gives 1 bytes: (71) "q" XFilterEvent returns: False KeyRelease event, serial 29, synthetic NO, window 0x1600001, root 0x105, subw 0x0, time 316658990, (470,254), root:(472,689), state 0x0, keycode 24 (keysym 0x71, q), same_screen YES, XLookupString gives 1 bytes: (71) "q" XFilterEvent returns: False
Those are they key press and release events triggered by typing a ‘q’. Pressing one of the volume buttons looks a little different:
KeyPress event, serial 28, synthetic NO, window 0x1000001, root 0x105, subw 0x0, time 316864564, (132,42), root:(134,477), state 0x0, keycode 121 (keysym 0x1008ff12, XF86AudioMute), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 28, synthetic NO, window 0x1000001, root 0x105, subw 0x0, time 316864684, (132,42), root:(134,477), state 0x0, keycode 121 (keysym 0x1008ff12, XF86AudioMute), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False
You’ll notice that they keycode indicates the XF86AudioMute button was pressed this time instead of q but the XLookupString returns 0 bytes.
Basically the three volume buttons are is associated with virtual X keys: XF86AudioMute, XF86AudioRaiseVolume, XF86AudioLowerVolume. It’s pretty straight forward to use xbindkeys to map these to alsa commands to manually mute, raise or lower the volue. My .xbindkeys looked like this:
"amixer set Master 2dB+" XF86AudioRaiseVolume "amixer set Master 2dB-" XF86AudioLowerVolume "amixer set Master toggle" XF86AudioMute
Some prefer to link these keys to the PCM volume control. I found that toggle (as well as mute/unmute) doesn’t work for the PCM channel. I’m honestly not sure what the PCM channel is even for so I reserve the right to change this in the future. There’s lots of howto’s out there with people implementing shell hacks to fake a mute / unmute for the PCM channel using xbindkeys if you’re interested enough to search.
So the above configuration and a quick entry in my rc.lua to kick off xbindkeys was enough to get this working. The one down side to using xbind keys: it doesn’t have a cool little volume indicator that pops up to show the volume level when you press your volume keys 🙂