I just got my n800 the other day, but I ran across the same thing that tz1 mentioned: I've got a button on my bluetooth headset (Moto H680) that doesn't do anything.

I coded up the idea mentioned here - bind the button_press event to a script that runs xte. The built-in media player needs a carriage return to play/pause, but you could modify this to do just about anything.

I posted the python code here along with an archive containing the latest sources for XAutomation with compiled binaries. Or, if you prefer, a second post with just the files executables.

Thanks for the xautomation build!

I tried something similar (using mpc to control mpd, no need for xte), except I used dbus-scripts. dbus-scripts is probably the cleaner approach, as that lets one daemon handle multiple event definitions installed separately, but I have trouble with dbus-scripts in session mode. It repeatedly segfaults.
So I found that there is an equivalent signal on the system dbus, and am using that. But Xautomation will be very handy for some other stuff.

Yeah, I found that I couldn't get the session dbus to work with dbus-scripts either, and I felt like learning how to do it with python-dbus. I'm still not sure how to get which button was pressed from the dbus "button_pressed" event, for headsets that support redial, voice, etc.

Actually, if python 2.3 will support the code, a quick fix would be to switch it from python 2.5, and save resources with pythonlauncher. In that case, I don't think there's really a difference between using dbus-scripts and my approach (except for the automatic init.d execution).

Either way

I may see if I can figure out how to package xautomation, but there's not debian control for it... perhaps I'll pull a version from something like Ubuntu Hardy and see what it officially requires.

Well, you might check the system dbus and see if you can tell by those signals. (There's really only one signal, rather than a press and release. So I think (from the way my headset works), that the one on the system bus is read by something, which sends the signals on the session bus. I only have a one-button headset (plus volume, which is handled separately), so I don't really know if there is any more there.

Thanks Benson, I'll give that a try.

Mine's got a "multi-function" button and volume controls, but depending on how long you hold the button it sends either an answer/hang-up signal, or a redial command. It seems like this is handled onboard, rather than on the phone, as both the press and release messages on the tablet only appear after the button is released (using dbus-monitor).

System dbus also seems to work a bit better with dbus-scripts (i.e. at all), so that might be a sign.

I'm not completely sure where the api for "com.nokia.osso_hp_ls_controller.headset" is, but it seems reminiscent of the bluez api for HSP, so I'm going to pull down the C code for that and see where it gets me.

As an update, it seems that the system DBus gets an AnswerRequested event from Bluez. I read through headset.c a bit, and the short version is that there's no support for multi-button headsets at the moment. A much more long-winded version is here if anyone is interested, but I didn't want to clutter up the forum.

On another note, switching python2.5 to python in my script does make it work with pythonlauncher... there's no real need for 2.5.