Ack! This site is moving to tomhorsley.com 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.
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
[General] busName=system interface=org.freedesktop.Hal.Manager member=DeviceAdded string=/org/freedesktop/Hal/devices/usb_device_47d_1020_noserial_if0_logicaldev_input exec=/home/tom/scripts/xinput-mouse-settings
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
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:
#!/bin/bash # 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