The TrackPoint pointing device pioneered by IBM and found on all ThinkPad laptops is awesome. My laptop only has a TrackPoint for a pointing device and I love it. They take about a week to learn, but once you do you will reach for it constantly, even when you have a mouse. Not having to move your hands is wonderful.

These devices have many configurable parameters to make them more comfortable. Under Linux, TrackPoint device configuration parameters are exposed as files in SysFS. For my system these can be found under /sys/bus/serio/devices/serio1, but that may varry depending on your ThinkPad’s hardware topography, and how much the Linux kernel has changed since this was written.

I like to change the parameters of my TrackPoint to be more sensitive. I used to do this using a script run directly by my system init scripts. This was messy and didn’t work reliably. If only there was some sort of userland system which received device events from the kernel and used them implement policy and userland functionality.

This is of course (part of) what UDev does. The following UDev rule can be placed in /etc/udev/rules.d/ and will initialize your TrackPoint to your preferred settings. (I’m in part posting this here so I can’t lose it.)

ACTION=="add|change", SUBSYSTEM=="input", ATTR{name}=="TPPS/2 IBM TrackPoint", ATTR{device/speed}="150", ATTR{device/sensitivity}="180"

You can set as many attributes as you like using the ATTR{<parameter name>}=”<value>” in the same line. Note that ‘=’ is an action of assignment while ‘==’ is a test of equality used in deciding if the rule applies (just like in C.)

GNU Readline is a wonderful library. It is easy to program with, takes care of what is a chore to implement properly and has a user configuration system that means all Readline using applications will have the same customizable behaviour.

I read somewhere that its nickname is “the GNU Trojan Horse.” Being so quick and easy to include in code, if often escapes notice that libreadline is license under the GNU GPL. The GNU-GPL, in contrast with the GNU-LGPL, requires that if libreadline is included your entire project must be licensed with the GPL in order to remain compliant with it.

I think it is for this licensing reason that some software does not use readline. A good example is the command `sqlplus`, the command line interface to Oracle database systems. `sqlplus` is part of the free-as-beer, closed source Oracle database tools. `sqlplus` has less command line features than DOS 5. At least in DOS 5 you could hit F3 to get the previous command recalled, and when you hit the cursor keys it didn’t insert crap into the line. For a command line where you are often trying out different SQL statements, often retrying or recomposing the same query, command history and command editing is a require feature. `sqlplus` is like a go-kart where to steer you have to get off and adjust the wheels with a wrench, then get back on. The task which is the tools main purpose of existence is very tedious to operate.

Enter the program `rlwrap`. `rlwrap` is an executable which places a readline proxy between what it reads from standard input and to what it sends to a command line program. Run a command like sqlplus through rlwrap by typing `rlwrap sqlplus` and bam, you have command line history, editing and filename completion. The best thing is that because `rlwrap` doesn’t modify binary executables to operate you can us it with any program, regardless of licence.

Any command which uses standard input as a command line can benefit; pacmd, xmodmap – both work.

Often I find myself transcoding large directories of multimedia files from one format to another. Usually a transcode is a single-threaded operation (not so for x264, but we’ll ignore that for now.) It’s rather inefficent to run only one transcode command at a time on a machine with multiple CPU’s as while the transcode with consume all of the CPU time of one of the processors, the remaining processors will be idle.

To use all processors at once we need to run jobs in parallel. Thankfully a tried and tested tool for building things based upon input things a rules with parallelization support already exists: the `make` command. Using make we can transcode as many files at once as we want.

There’s one catch though, Make is a little bit blind when it comes to files which have spaces in their names. I was surprised by this, but I couldn’t find a good way to escape spaces in Makefile syntax. As most media files contain many spaces this was a problem.

Undeterred, I came up with a way around the space problem; Create a symbolic link for each source file that is Make friendly, run Make and then rename the outputs back to something useful and delete the symbolic links.

The following script is the result. This script converts all the audio files passed as arguments to audio files in the Ogg Vorbis format. The actual transcoding is done by the `avconv` from libAV. I use libAV as it accepts many different input files, and it also converts the metadata when transcoding. The script is pretty generic, and it should be possible to easily change it to convert to formats other than Ogg Vorbis.

http://art.ified.ca/downloads/make-vorbis.sh

Multiple-monitor support for X11 has greatly improved from when I started using it. For starters, you no longer have to edit a root-owned text file and restart your Xserver. Now we have the X11 RandR 1.2 extenstion and you can used use the command line on-the-fly or one of the many GUIs to change your output configuration. (If you don’t think this feature is that amazing, fair enough.)

All the major desktop environments have GUIs for display output configuration. Many times these desktop environments attempt to set output configuration at login. My primary computer is a laptop. At home I have a dock with an external monitor. Thus, 90% of the time my display output is in one of the two configurations: single headed laptop panel, or dual-headed laptop panel and external monitor. All the functionality I require is to toggle these modes. In Windows one can use the keystroke Super+P to quickly do so. In Gnome, whatever key generates XF86Display does this as well (if the gnome-settings-daemon xrandr plugin is enabled, which it is by default.)

The catch is that sometimes Gnome’s display output applet gets things wrong, or annoyingly my hardware likes to the generate the XF86Display keystroke when pressing Fn+F7, Dock Eject, Lid Open, Lid Close… etc. This causes my display configuration to change when I shut the lid (annoying), put the machine to sleep (annoying) or when I eject it from my dock (annoying if it didn’t notice that the external monitor isn’t there anymore.) I often find myself going to the command line and doing my output configuration manually.

Then a thought occurred; since I really only use two xrandr commands, there has to be a way to automate the process. One shell script plus Zenity later and this is the result:

#!/bin/bash
# multiple-monitors.sh: Quick-and-easy xrandr(1) arguments picker.
# (c) 2012 Arthur Taylor Permission is granted to any person to use, copy,
# modify, merge, publish, distribute, sublicense, and/or sell this script.
# This script is provided "as is", without warranty of any kind.

ICON="/usr/share/icons/gnome/48x48/devices/video-display.png"

XRANDR_COMMAND[0]=" --output LVDS1 --mode 1440x900 --output VGA1 --off"
XRANDR_COMMAND[1]=" --output LVDS1 --mode 1440x900 --output VGA1 --mode 1280x1024 --right-of LVDS1"
XRANDR_COMMAND[2]=" --output LVDS1 --off --output VGA1 --mode 1280x1024"
XRANDR_COMMAND[3]=" --auto"

TO_RUN=`zenity --list --width=640 --height=240 --window-icon $ICON --title="XRandR Settings" --text="Pick (or edit) an XRandR configuration:" --column="command" --hide-header --editable "${XRANDR_COMMAND[@]}"`

if [ "$TO_RUN" != "" ]; then
    xrandr $TO_RUN
fi

All this script does is take chose text from the chosen list entry and pass it as arguments to the xrandr command (see xrandr(1) man page.) I know this isn’t to most user-friendly method of changing display outputs, and it doesn’t provide failure feed-back, but is quicker than opening a terminal and typing it from scratch.

If you use Openbox, then a keboard shortcut for can be done by simply adding the following to your rc.xml keybindings section:

<keybind key="XF86Display">
  <action name="Execute">
    <execute>bash /the/path/to/multiple-monitors</execute>
  </action>
</keybind>

A patch I submitted to the xorg-devel mailing list marks the end of the K_OFF story described in my previous post <link>. Almost a year later and the xserver handler to vacuum away needless buffered key events, preventing a kworker kernel thread going nuts, is no longer needed. Shortly after it was reviewed and pulled into X.org 1.12-rc1. The commit is fairly small: ff891bbf68caefc22cabb541b6b56af086ac2280.

On a whole, I’m proud to have contributed to two major open source projects, the Linux kernel and the X.org Xserver, albeit only two small patches. During the process I learnt a lot about how F/OSS projects organize themselves and how to communicate with developers and project leaders. I would like to state that the responses I got back from both projects were patient and helpful, and on the whole the process, while a learning experience, was quite easy.

Specifically, I now know about git-format-patch and git-send-email. Also useful to know is that you can setup Git to send through Google’s SMTP servers if you have a GMail (or a GMail based domain email) account. The settings (for the record so I don’t lose them) are:

sendemail.smtpserver = smtp.gmail.com
sendemail.smtpserverport = 587
sendemail.smtpencryption = tls
sendemail.smtpuser = <your Google domain account>

Last December I noticed a strange problem with my Linux system. Every once in a while I would experience about 1000 wakeups/second, a condition that would persist until I restarted my Xserver. These wakeups seemed pointless, failing to use more than 1% CPU usage, but none the less would cause it never to enter lower sleep states, and as this is on a laptop, eat more battery power. I was confused as my friend had similar hardware to mine, but failed to experience the intermittent wakeup problem. A little bit of investigation revealed that this was caused by the kernel tty-layer helper workqueue named “flush_to_ldisc” spinning in an infinite wake up, do no work and reschedule loop. More investigation showed that the loop was caused by my non-standard Xserver configuration not enabling a workaround of an old kernel behaviour.

Previously the Xserver on Linux received its keyboard events by reading from the virtual terminal device. The Linux console works by having a range of virtual terminals, only one of which is connected to the actual console at a time. Each VT has its own input and output buffers and also maintains its own state. The way that keyboard events are handled in the VT is called the keyboard mode. The normal keyboard mode, the one used by a text console, is translate mode, in which the kernel translates scancodes to characters, handling special keys and buffering the rest in the VT. As the Xserver does its own keycode handling and translation it uses raw mode in which raw key up and down events are buffered in the VT.

A new way to handle input devices, the Linux Input Subsystem, became the input base for kernels since 2.5. This subsystem, among other things, exposes the individual input devices to userspace as individual character devices. The X.org Xserver by default now only uses the input-evdev driver to get all keyboard input directly from the input subsystem rather than through the VT. This is great except for a few, shall we say growing problems. First, if the virtual terminal’s mode isn’t set away from translate, special keys are still handled by the kernel, causing ctrl+c to kill the Xserver and other shenanigans. The second problem is that while the Xserver opens a VT, it no longer reads input from it. Every key press gets buffered in the VT and as nothing reads from it, eventually overflows.

The infinite work queue I witnessed was caused by the VT input buffer trying to flush new key events when full.

The first problem I listed with fixed in the Xserver by setting the current VT to always be in raw mode [1]. The second problem was fixed in most cases by setting up a separate task to call flush on the VT input buffer whenever stuff appeared in it [2]. The Xserver would only do this if the server option “AllowEmptyInput” was true, in which case the Xserver knew that input-kbd wouldn’t be in use. If AllowEmptyInput was false but input-kbd wasn’t used the input buffer would fill up. This latter configuration was what triggered the bug for me.

All of this seems rather hack-y and sub par. Surely their should be a way to simply disable the VT input buffer? This being open-source, I took it upon myself to fix the issue. The simplest way would be to create a new console keyboard mode called “off” in which both kernel special keys are ignored and the input buffer remains empty.

My first try was to deregister the tty layer’s input subsystem handler if the current terminal’s keyboard was in off mode. This solution is nice in the sense that it stops a lot of redundant code from being executed per keyevent at the source. Unfortunately there was a complication with shift (or modifier in X11 parlance) keys and shift states.

The second try simply returns early before key events are buffered or special keys are handled. This solution was cleaner, always worked, and only involved nine lines of changes.

After testing the different situations and using it for a month and a bit I decided to try and get the changes into the main kernel tree. A few emails and two weeks later, boom, my patch was accepted by Greg KH into the tty-next branch [3], then pulled into the linux-next branch awaiting the next merge window for linux 2.6.39. The whole affair was quite easy and satisfying. The next step now is to write up a more formal patch for the X.org Xserver. The changes to the Xserver are quite minimal but will require that the updated kernel headers to be installed at compilation time.