Posts Tagged ‘linux’

Mouse Button Remapping with HAL

June 13th, 2009 • • 2 Comments

I’ve had a Logitech MX1000 mouse for a few years now, and the two most important features for me have been the ergonomic build and the few extra buttons. Something I’ve always found with many-buttoned mice is that the side button closest to the thumb is a much more ergonomic way to “middle click” than the actual middle mouse button—it’s a much more natural motion. Middle clicks are quite useful these days, especially with them being a standard way of closing tabs (and opening them in browsers), and having such a popular button perched on a rocking and rolling peak is far from ideal.

Since I’m primarily a Linux user, I don’t have Logitech’s own SetPoint software at my disposal, so I’ve always had to find a way to get this functionality in some other way. When I first got the mouse, this method involved deliberately using a “basic” mouse driver (referred to in xorg.conf as “IMPS/2″), which didn’t support many mouse buttons. The effect was that the button mappings wrapped around, leaving button 8, my preferred “middle click”, mapped to button 2 (8 mod 3), the real middle button.

Unfortunately, newer Xorg versions became smarter and better capable of handling more buttons, and this workaround ceased to function. For the next while, I used something even more hackish: xbindkeys combined with xmacroplay to simulate a middle click with the following part of my .xbindkeysrc:

"echo ButtonRelease 8 ButtonPress 2 ButtonRelease 2 | xmacroplay -d 0 :0.0 &"
    b:8

The downside to this solution is that there are some cases where the button events don’t work correctly, one of them being open-in-tab from a bookmark menu in Firefox. It seemed the best solution would be to get Xorg to remap the buttons in such a way that button 8 really was just an extra button 2. The “xinput” utility lets you set button maps in this way—this wiki entry shows how to remap mouse buttons (even if for a different purpose).

This method worked fine, and I put it in my startup programs for GNOME, but it didn’t persist after suspend/resume. It appears that when resuming, USB devices get “reattached”, and therefore don’t keep the settings applied to them the last time they were attached. The workaround for this is to set a policy using a HAL (Hardware Abstraction Layer) .fdi file. These files live in /etc/hal/fdi/policy (at least they do on Ubuntu) and allow you to set various properties on input devices. This page on the Ubuntu wiki gave me the recipe I needed to remap buttons based on the device name. I ended up with the following .fdi file (which I saved at /etc/hal/fdi/policy/logitech-mx1000.fdi):

<?xml version="1.0" encoding="UTF-8"?>
 
<deviceinfo version="0.2">
 
<!-- Remap Logitech MX1000 buttons so that the most accessible side button
     acts as a middle button -->
 
  <device>
    <match key="info.product" string="Logitech USB RECEIVER">
      <merge key="input.x11_options.ButtonMapping" type="string">1 2 3 4 5 6 7 2</merge>
    </match>
  </device>
 
</deviceinfo>

Now, whenever my Logitech mouse is connected, it gets the buttons remapped—this includes when resuming from suspend. Problem solved… until things are changed again of course!

Enable Bitmap Fonts on Ubuntu Jaunty

April 11th, 2009 • , , • 8 Comments

I like to use tiny bitmap fonts like MonteCarlo for programming, but by default Ubuntu has bitmap font support turned off.  From (at least) Gutsy through to Intrepid, this method worked for enabling bitmap font support, but after installing the Jaunty beta I found this no longer works.

Luckily, after a brief look in /etc/fonts, I found that font configuration now follows the nice pattern of a conf.avail directory containing all the available configuration parts, and conf.d containing symlinks to these parts.  This makes enabling bitmap fonts even simpler now:

# "Un-disable" bitmap fonts
$ sudo rm /etc/fonts/conf.d/70-no-bitmaps.conf
# Clear the font cache
$ sudo fc-cache -f -v

Now you should be able to drop bitmap (i.e. PCF) fonts into ~/.fonts as you would with TTF fonts and be able to use them with no extra hassle.

Persistent Remote irssi Session

March 28th, 2009 • , • No Comments

I’ve recently moved back to using irssi as my IRC client, because when combined with GNU screen it can be kept independent of a graphical session, or even better, of a particular client machine (if you have a server somewhere). Since I have a home fileserver at the moment, I want my IRC client to always be running there. However, my usual workflow to do this is to open a terminal, SSH to the server, resume screen, move the window and resize it. This is far from optimal for something I usually want open…

Instead, I pieced together a command that I can use as a panel shortcut to do it all for me:

$ gnome-terminal --geometry 100x30-0-0 -x \
        ssh <hostname> -t "screen -D -RR -S irssi irssi"
gnome-terminal –geometry 100×30-0-0 -x
Open “gnome-terminal” at the bottom right of the screen with a size of 100 characters by 30. Run the rest of the command inside the terminal.
ssh <hostname> -t
Connect to <hostname> and execute the supplied command in an interactive pseudo-TTY.
screen -D -RR -S irssi irssi
Do whatever necessary to gain control of the “irssi” screen session if it exists, otherwise create it and run irssi inside it.

MPD + PulseAudio + Ubuntu Intrepid (8.10)

March 21st, 2009 • , , , • 12 Comments

Update (2009-04-12): It appears that in Jaunty everything now obeys the system-wide setting properly, so you only need to edit /etc/default/pulseaudio and add the user to pulse-access.

I’m a big fan of Music Player Daemon (MPD), and up until the last few months I used it almost exclusively.  It’s lightweight, it’s good at what it does, and there are a lot of different frontends available.  One of the things I like most is that it’s not tied to a graphical session in any way—you don’t need a GUI open for it to be playing music.  Normal usage of MPD involves it being started and stopped as a system service.

Unfortunately, this doesn’t play too nice with the concept of how PulseAudio should be used.  PulseAudio is very user- and session-centric, and the recommended setup means than when nobody is logged in, no sound is going to be playing.  While MPD is capable of playing to a PulseAudio server just fine, having the sound server tied to the graphical session means it doesn’t have a sound device to attach to at boot, and the sound device suddenly disappears if the user logs off.

Ubuntu has used PulseAudio for as many applications as possible by default since Hardy (8.04), and while it can be removed, doing so can make life difficult.  This led me to pursue the option of a system-wide instance which everything uses, and which is always running.  But no matter how hard I tried, I got stuck with the same bug: starting GNOME would always result in a per-session instance being spawned in addition to the system-wide one, the two would fight over the sound card, and I would have to manually kill the new one every time I logged in.  Eventually I’d had enough of this and started using something else.

Today, I decided to take another stab at getting this set up properly and finding out where that second PulseAudio instance was coming from.  Thanks to the help of a couple of people in #pulseaudio on FreeNode IRC, I was able to figure out how to do this, so here is the method I used for the benefit of anybody else in the same position.

Stop PulseAudio spawning per-session

By default PulseAudio puts a script in /etc/X11/Xsession.d which causes a “pulseaudio” instance to be spawned with every X session.  The first step is to move this script somewhere else so it’s never run:

$ sudo mv /etc/X11/Xsession.d/70pulseaudio /root/

The second cause of “pulseaudio” being spawned is less obvious.  There is an Esound compatibility layer for PulseAudio so that applications depending on it still work, transparently.

$ ls -l /usr/bin/esd
lrwxrwxrwx 1 root root 9 2009-03-04 11:03 /usr/bin/esd -> esdcompat

However, as of Ubuntu Intrepid (8.10) there is pretty much nothing which depends solely on Esound, but it still gets spawned when GNOME starts.  This causes a PulseAudio session to be spawned for the current user if one can’t be found.  The simple but ugly fix is to move this link to somewhere else:

$ sudo mv /usr/bin/esd /usr/bin/esd.bak

Set up a system-wide PulseAudio instance

To get PulseAudio to actually start on boot, you need to set a variable to tell the init script you want this to happen. Make sure you have the following line in /etc/default/pulseaudio:

PULSEAUDIO_SYSTEM_START=1

Any users that will be using the system-wide PulseAudio instance need to be members of the correct groups. This will most likely be your own user, plus whatever user MPD is running as (”mpd” by default). For each of these users, do:

$ sudo usermod -a -G pulse-access <user>
$ sudo usermod -a -G pulse <user>
$ sudo usermod -a -G pulse-rt <user>

Getting it up and running

First thing’s first, you need to tell MPD to use PulseAudio. This can be achieved by adding the following to /etc/mpd.conf:

audio_output {
       type    "pulse"
       name    "My MPD PulseAudio Output"
}

If you’re feeling lazy, the easiest thing to do right now would be reboot. Otherwise, you’ll need to kill all “pulseaudio” instances, restart the system-wide instance, and restart MPD.

$ sudo /etc/init.d/mpd stop
 * Stopping Music Player Daemon mpd                   [ OK ]
$ sudo killall -KILL pulseaudio
$ sudo /etc/init.d/pulseaudio restart
 * Stopping PulseAudio Daemon                         [ OK ]
 * Starting PulseAudio Daemon                         [ OK ]
$ sudo /etc/init.d/mpd start
 * Starting Music Player Daemon mpd                   [ OK ]

Finally, log out and log back in again to allow your per-session pulseaudio instance to die and for your new group memberships to take effect.

Caveats

  • You get “real-time” processing without any extra effort; by default the system-wide instance will run with priority -11.
  • Some apps are not PulseAudio-aware, but they can usually use an ALSA output; this guide shows you how to redirect ALSA through PulseAudio if you have any problems with the default setup.
  • Updates may undo the moving-a-file type of changes.

My painless Linux “upgrade” process

January 7th, 2009 • • No Comments

I like to keep up to date with the latest version of any Linux distro I use (naturally), but for some reason I don’t trust the upgrade process to work properly and/or not leave a load of cruft behind.  I’ve actually attempted an upgrade once just to try and get over my upgrade fear, but instead it went horribly wrong and convinced me to not try again for a long time.

There is a simple way to make reinstallations painless enough that you don’t need to offer yourself up to the upgrade gods, and it takes only a small amount of forward planning.  Always always always use a separate home partition! Keeping your home partition separate allows you to go as far as reformatting your main operating system partition without losing any of the data you really care about.

Note: just in case it’s not obvious, my username is ‘alan’ - replace it with your own username!  If you have multiple users, repeat operations on each user’s home directory.

Here is my typical upgrade/reinstall process.  If you’re planning on using this method, please read the whole thing before starting and make sure you understand what you’re doing and why.  A lot of this is done as root and mistakes can be painful.

1 - Prepare

Your /home partition isn’t going to be reformatted if everything is done correctly, so if you know what you’re doing you shouldn’t even need to do a full backup.  However, you’ve probably got some other things on the root partition that have been changed that you want to keep, at least for future reference.

# Backup /etc
sudo tar czvpf /home/etc.tar.gz /etc
# Backup root's home directory
sudo tar czvpf /home/root.tar.gz /root
# Backup anything else you might want to /home, for example MySQL databases
# (maybe backup /var the same way as above?)
# ...

Next you need to make a note of which partition is which so you don’t accidentally format the wrong one:

$ df
/dev/sda5             11718932   2419420   9299512  21% /
...
/dev/sda7             44133352    219500  41671984   1% /home

So in this case, /dev/sda5 is what you’ll be reformatting and installing your new operating system on, and /dev/sda7 is the one you don’t want to touch in any way whatsoever.

Next you’ll want to write the fstab line for your home partition somewhere so you can use it on your new installation.  The following command will get that from /etc/fstab for you:

$ grep "/home" /etc/fstab
/dev/sda7      /home      ext3     defaults,relatime      0     2

The final preparation step is to move your old home directory somewhere. To do this you’ll need to be logged in directly as root. If you’re running an Ubuntu-based distribution and haven’t set the root password before, do so:

$ sudo passwd

Log out of your graphical session, switch to a virtual terminal (e.g. press Ctrl+Alt+F2), and log in as root. Move your old home directory:

$ mv /home/alan /home/alan-old

Everything should be ready now - time to reboot into the installer of your distro of choice!

2 - Installation

Just install as usual, feel free to obliterate your old root partition but make sure you don’t touch your home partition! Install as if your home directory will be on your root partition along with everything else.  Reboot into your new fresh Linux installation.

3 - Juggling

Now all that’s left to do is get your home directory onto your home partition, get your home partition mounted and move all your files back to their rightful places.

Yet again, this process will require you to log in directly as root to move the home directory around, so set the root password as before if necessary for your distribution.

Now log in as root on a virtual terminal (e.g. Ctrl+Alt+F1) to mount your home partition somewhere, copy your new home directory across, and unmount it again.

$ mount /dev/sda7 /mnt
$ cp -a /home/alan /mnt/
$ umount /mnt

Now we want to make sure the home partition get’s mounted at /home as it should. Edit /etc/fstab with your editor of choice and add the fstab line from earlier. To make sure everything is correct, mount the home partition in a way that’ll use fstab, and check that both the old and new home directories are there:

$ mount /home
$ ls /home/
alan   alan-old

Just in case your user ID has changed, make sure your old home directory is owned by your new user:

$ chown -R alan:alan /home/alan-old

At this point, you should be finished with using the root account, and can log in as normal. If you want to lock the root account (in the way Ubuntu does by default), run

$ sudo usermod -L root

4 - Get your files

Now you should be able to browse both your new and old home directories using your file manager of choice. Open one for each, show hidden files, and start dragging stuff around!

This step might take some time, but has the added advantage that you get to learn where every application stores its user files, and also gives you the opportunity to clear out some junk you didn’t need, clean up your directory structure, or whatever else.

Final notes

This process is probably slower than an upgrade, especially considering the step of sorting your old files into your new home directory. However, it gives you very direct control over the process, lets you start with a nice clean copy of your operating system, and if done correctly doesn’t require a full backup to be made.

I much prefer this method to doing an upgrade because it leaves you free of the “old version cruft” that accumulates when you upgrade—an operating system upgrade is a complex process and is never going to handle every edge case.

If you trust all of your applications to handle old configuration files etc. correctly and you want to save some time, you can skip all of the steps relating to moving/copying of your user’s home directory, so that when you mount your home partition your old home directory is used.  If reinstalling rather than upgrading, I tend to do this.

Important: While I mention that this can be done without a backup, doing so is at your own risk.  Generally speaking it is prudent to backup anything important to somewhere outside of your machine before doing any operating system installation to protect against mistakes.  Otherwise, be extremely careful!  I do things this way because my home directory is always too large to backup anywhere, but I also run an automated nightly backup of the small, important stuff.

Comments and corrections are welcome!

Why I dislike PulseAudio (for now)

December 17th, 2008 • • No Comments

Before this sounds like a rant, I’d like to first say that I think PulseAudio is a very nice concept, from a technical perspective.  It’s about time Linux got a managable sound subsystem, and some of the features–such as network streaming and synchronised playback–are quite impressive.

However, one thing that really irks me is that, as deployed by major distributions, it appears to enforce the narrow-minded view that a desktop is used by only one person, and that sound is only ever going to play when somebody is logged in to a graphical session.  Anybody who uses MPD has probably experienced the pain caused by this already.  Unfortunately my experience so far with Ubuntu Intrepid is that trying to change this results in even more pain.  Having set up a system-wide instance I’m now in the position where the first time I attempt to play sound works correctly, but any subsequent attempts fail until I kill a per-session PulseAudio instance that has magically spawned (even though I’ve set it not to).  Once the per-session instance is dead, I have no more problems and everything works perfectly until the next time I log in.

I’m currently trialing Fedora 10 on my desktop, so I’ll update this post if I have any more luck there.  Feel free to correct me in the comments if I’m just being stupid or missing something!

Edit: I’ve since fixed this problem: MPD + PulseAudio + Ubuntu Intrepid (8.10).