Tomáš Janoušek, a bug slayer

Vibration bell for PuTTY for Symbian

2010-10-08T00:00:00-07:00

PuTTY is probably the most used application on my phone. I use it to connect to my server where I read/write e-mails in mutt and communicate with the outer world using irssi and bitlbee. I suppose most PuTTY users start it only whenever they need to fix something at their servers, not as a primary communication tool. They didn't miss a function to alert the user whenever something happens in a terminal.

I did, however. I wanted to start PuTTY, attach a screen session and put the phone in my pocket, knowing that it would vibrate whenever something interesting happens. I always hated that whenever I had sent a message to someone, I had to look at the screen regularly to check whether he replied or not. So that's my motivation.

The solution was obvious, I implemented the do_bell function in PuTTY for Symbian and made it vibrate for a few hundred milliseconds. The source code is here: http://github.com/liskin/s2putty. A prebuilt package for s60v5 is in downloads. Let me know if you need a binary for some other version of Symbian.

Multiseat on demand: Split your computer into two whenever you want

2009-11-22T00:00:00-08:00

We needed to make three computers out of two yesterday, so multiseat was the keyword I googled for. Having found a bunch of howtos all starting with “make these changes to xorg.conf and gdm.conf”, I took the best from all of them and put together a solution requiring no single restart of X server. What I got was this:

Well, what's the problem? Why didn't I just take the first howto I found? I wanted to have a sort of “on demand” multiseat, that I can start and stop whenever I want, without ever touching my main X server and its configuration, without losing my open windows — even without having to rearrange them.

What did I need?

new enough X.org server and Xephyr server with input hotplug support (I used 1.6.5),
spare USB keyboard and mouse, spare monitor,
clever window manager with per-screen workspaces (that's the feature that lets me switch the external monitor to workspace 12 and still be able to switch workspaces on my laptop's display) — I used xmonad, of course.

The theory is that the other seat will run in Xephyr, using the keyboard and mouse I tell it to use. Xephyr can do that, nowadays, we only need to solve three little problems:

main X server uses that keyboard and mouse as well, and we need to disable that in runtime,
/dev/input/eventN is accessible to root only by default,
a lot of keys don't work in Xephyr at all :-).

Feel tree to skip the explanation of these:

The xinput command can be used to set device properties, and the “Device Enabled” property is what we're looking for. Given a device id, this is how we disable the device in the main X server:
```
 $ xinput list-props id | \
 perl -ne 'if (/Device Enabled $(\d+)$:/){ print $1 }' | \
 { read prop; xinput set-int-prop id $prop 8 0; }
```
Being in a hurry, I added Xephyr for my user to /etc/sudoers. You may want to create udev rules to set correct permissions instead.
This seems to be caused by Xephyr not using the evdev ruleset for XKB configuration by default. Running setxkbmap with -rules evdev seems to fix this problem (see the script for details). Xephyr still seems to have problems with autorepeat, and I guess that tweaking it for each keycode with xset r might fix it.

Having solved these problems, I wrote a small script that disables the input devices in your main X server and launches Xephyr that uses them, fixing keyboard afterwards: http://store.lisk.in/tmp/perm/multiseatxephyr

If called without parameters, it prints a short usage instructions. You'll have to look into /proc/bus/input/devices to get event devices, and at the xinput list output to find input device ids. It isn't very robust, but in most cases you'll be interested in the last two input devices.

Xephyr is running, with access control disabled, all you need to do now is to su to another user, export DISPLAY=:1 and run startkde (or anything else).

If in trouble, consult the documentation. There are a few links at the X.org wiki: http://www.x.org/wiki/Development/Documentation/Multiseat

Going tiled.

2009-10-28T00:00:00-07:00

I had been using Fluxbox for 7 years when I finally decided it's time for change last Friday. As my friends expected, I left it for xmonad. Seven years is a long time and for me it meant that I became a Fluxbox developer. Therefore, I should say some nice goodbye.

It all started in 2002 when a friend of mine switched me to Linux. I installed it onto my father's laptop, which only had 32 MB of memory and quickly realized that GNOME, KDE and Mozilla aren't for me. Someone gave me a tarball of fluxbox 0.1.12, I installed it, and liked it. Unfortunately, I have no screen shots or photos from that time.
(just this one: http://foto.nomi.cz/d/22669-2/ja_v_klobouku.jpg :-))

Later that year, I installed fluxbox 0.1.14 (the last in 0.1 series) onto my “workstation” and it turned out that I would stick with that old version for another 4 years.

The look of my workspace evolved a little over the years. I chose a few shots that demonstrate that :-).

In the meantime, Fluxbox team was working hard on the 0.9 series, hoping to get it stable enough for 1.0. Every time I tried it, it seemed buggy and slow, bringing nothing new other than transparency and eye candy. The one or two little features I liked were easy to implement in 0.1.14, anyway. So I stayed for 4 years.

Then, Mark Tiefenbruck jumped in and made things move faster in 2006. Later that year, seeing a lot of activity in its svn repo, I decided it was time for me to jump in as well. Took me only a few patches and it was stable enough for me to use. I even added some little features I wanted, and managed to get some of them included in official Fluxbox repo.

At the end of 2007, Fluxbox switched from svn to git and I was given push (“commit” in svn terminology) access. That year X.org became capable of switching between single- and dual-head without restarts and I added proper handling of this stuff to Fluxbox. After that, I had a window manager I was fully satisfied with. Those few features that never made it into the official repo were waiting for some polishing on my side that I was supposed to do after Mark does something I don't really remember what it was. I'm not sure if he did it, for some time I thought he didn't, and then I focused on other things and didn't want to hack the window manager that worked perfectly for me. Well, my fluxbox binary is now more than a year old and will remain that way. Sorry for that, Fluxbox is a great window manager, I'd like to thank the people around it, I learned a lot thanks to Fluxbox and the team.

The last day I used Fluxbox, it looked more or less like this:

And one day I switched to xmonad. That day was last Friday. Being a bug-magnet (as you may have noticed), I've already submitted two patches. But that's fine, neither was to xmonad core, both were for xmonad-contrib. (I don't want to blame Fluxbox either. That old 0.1.14 was nearly perfect and latest versions are probably quite stable as well.)

I really like the configurability of xmonad and the layout modifiers concept. Also, xmonad-contrib is a huge and very nice collection of useful stuff. I feel that I'll be submitting more patches (hopefully more than bug fixes) in the future.

My workspace now looks like this:

So, again, thanks and goodbye to Fluxbox, and I'm looking forward to having some fun with xmonad :-).