Ack! This site is moving to since Comcast's efforts to improve their world's worst customer service ranking apparently include terminating web hosting for their existing customers.


Note that recent versions of gnome ship with a more official way to do this. You can set the hotplug-command key in the dconf schema org.gnome.settings-daemon.peripherals.input-devices, and the command will be run by the gnome-settings-daemon when devices like mice and keyboards are plugged or unplugged. See this blog for more details.

Download xdbusd.tar.bz2.

The xdbusd name is a play on the xinetd name. In much the same way xinetd listens for network connections and runs other programs, xdbusd wull listen for dbus messages and run other programs.

xdbusd was born from this thread in the xorg mailing list plus my frustration at things that never work right in linux because people are too busy improving them to worry about making it possible to use them.

A low level tool like this, operating on dbus messages, will probably be just what I need for the next improvement and the one after that and the one after that (until they improve dbus out of existence anyway).

So, how to figure out how to use xdbusd?

You will want to run dbus-monitor to see what dbus messages show up when the events you are interested in occur. For me, I wanted to know what happens when I unplug and plug my usb mouse:

dbus-monitor --system
signal sender=:1.0 -> dest=(null destination) serial=1651 path=/org/freedesktop/Hal/Manager; interface=org.freedesktop.Hal.Manager; member=DeviceAdded
   string "/org/freedesktop/Hal/devices/usb_device_47d_1020_noserial_if0_logicaldev_input"

It sends lots of signals, but the one above is the last signal I get after plugging the mouse back in. I figure the last signal is the one that means the mouse is really there now.

This also shows a limitation of the current xdbusd. You see that the signal above comes with a single string delivered with the signal. Those are currently the only dbus signals xdbusd can handle. (It is written using the Qt dbus interface code which is far simpler to use if you know exactly what you are going to get :-).

Anyway, the output from dbus-monitor needs to be turned into a input file for xdbusd. By default these files all live in the ~/.xdbusd/ directory and look like this:


The busName comes from the --system or --session argument you gave to dbus-monitor when running it to find the interesting dbus messages. You may need to try it twice to find which standard bus the interesting message shows up on.

The interface, member, and string settings are all extracted directly from the output of dbus-monitor.

You may also specify service and path, but leaving them out usually doesn't change anything.

Give the file any name you want, but give it the suffix .xdbd. All the .xdbd files in the directory will be read at startup. (By strange coincidence, this happens to be a simple file format supported by the QSettings class, so it is easy to read into a Qt program).

The exec line is the interesting one, and the main reason xdbusd exists. In this example, when it sees the message with the string above, it will run a shell script that looks like:

xinput --set-button-map \
       'Kensington      Kensington Expert Mouse' \
       1 8 3 4 5 6 7 2
xinput --set-int-prop \
       'Kensington      Kensington Expert Mouse' \
       'Evdev Drag Lock Buttons' 8 2 1

So, fill up your ~/.xdbusd/ with .xdbd files, start xdbusd in the background when you start your X session, and all your handy scripts will be run when the corresponding dbus signals show up. Note that you may also want to run your scripts once before starting xdbusd to get the initial settings applied.

Page last modified Sun Jan 15 12:49:16 2012