The answer/disconnect button on Bluetooth headsets currently does not send a signal to dbus. We are currently working to add a python connection for the Saera app (Siri clone) and for our early work there is already useful support for wired headsets with Headset-Button-Enabler, but the Bluetooth answer button is unsupported. Any help tracking down and making usable the Bluetooth answer button would be a major contribution to the ongoing work.
I hope we can get this working as there is an excited community working on voice dialing and advanced voice control of the N900 and N9. Headset voice control is the most logical way to interact with your phone if your hands are occupied driving a car or bicycle.

You can see our progress in the headset control for Python thread http://talk.maemo.org/showthread.php?t=84827
Saera thread http://talk.maemo.org/showthread.php?t=84753

Most of the work has already been done for wired headsets with these packages:
*Headset Button Enabler - enables wired headset to be used outside calls
*Headset Control - uses wired headset to control Media Player
it would be nice to either add Bluetooth functionality to these packages (also possibly benefiting Skype with some work) or create a parallel package for Bluetooth support.
Thanks!

To rephrase the question simply, what signal is sent from a bluetooth headset when the answer button is pressed?
Where can this signal be found for use?
Currently the bluetooth answer/end button signal does not go to dbus.
Thanks

I think I'll order cheap BH95C bluetooth headset and try to check how to make the button work (if it'll be compatible with n900 at all).

To make things a bit more clear:
- Headset Button Enabler is a package which changes policies in system that the state of button on wired headset can be read at all
- Headset Control is a package which has a deamon "headset-controld" which fires dbus signals whenever button is pressed

Not sure the process but maybe Bluetooth Headset Control needs a garage page so everyone can jump in and we can see it on the repos.

What in my personal oppinion would be best to achieve is having these packages:

-Headset Button Enabler - a package which changes policies in system to allow both wired and wireless headset buttons (all buttons) to be accessed by different apps (currently we cannot access e.g. "green" button - in other words answer call/make call button - on bluetooth headsets, as reported by trlopes1974 here: http://talk.maemo.org/showpost.php?p...8&postcount=18 )
-Headset Control - a package with ONLY deamon sending to dbus events on headset (both bluetooth and wired) button presses, and Control Panel applet with settings (to set which app should receive and take actions on this dbus signals), with plugin architecture (currently it's only part of whole "headset control" package, it's the headset-controld deamon)
-Headset Control - Media Player plugin - currently part of "headset control" package responsible for controlling media player
-Headset Control - Saera plugin - similar like above, but would tell that it's saera that should be receiver of dbus events (this doesn't need to be separate package, it can be part of saera)
etc.

I mean, I think we should have three components:
1. headset control enabler
2. headset control deamon
3. packages which would like to use headset button should provide config files and user should be able to select via control pane which one should be currently active. This way the singnal would have not only "ButtonPressed" : "Phone", but also e.g. "ExpectedReceiver" : "mediaplayer" or "ExpectedReceiver" : "saera", etc. (depending on settings in control panel)

I hope I made myself clear, any feedback from other devs and "normal" people (users) is welcome, I think this is the project I want to code now

It would need to be considered carefully, as to not destroy compatibility with, for example, BH-214 - that got full bluetooth control (i.e. play/pause, forward, backward, and answer) working fine.

/Estel

I agree. It should be considered and decided, but some solution should be worked out and implemented to avid total mess and compatibility problems. In current situation if we had QRadio, headset-button-control (and maybe other packages using headset button) installed and running at the same time, pressing button on headset would result in complete mess.

Play/pause, stop, forward and backward are working fine and it should not be changed by any updates, I agree. The answer and reject buttons are only working for actually answering or rejecting calls, we don't have access to them (on bluetooth headsets, on wired headsets these can be enabled).

Current package for wired headsets does some checks (from what i worked out while reading code) if someone's not calling us at the moment or we are not currently inside a call etc. and does nothing if any of these checks returns true, so the default behaviour is preserved. That's quite obvious none of us would like to break any current behaviour so any changes like that would require caution. And finding all programs using headset button and writing patches for them for newly developed system.

Not entirely true - double-clicking of answer/end button result in re-dialing last number. At least, when sitting idle on hildon-desktop.

/Estel

Does it generate any dbus event? Or can this behavior be changed to different action? By saying that we don't have access to them I meant that we cannot program them when writing our own software. Correct me if I'm wrong, I have never used bluetooth heaset with n900 yet