how to capture buttons from Bluetooth headsets?

[The PocketTV Team]

Some Bluetooth headsets (with profile AVRCP) have control buttons such as forward/play/pause typically used to control a media player.

How can applications capture those buttons?

Do they send WM_KEYDOWN messages to the active application?

if yes, what are the virtual-keys for those various buttons? Are they standardized? Are they non-standard and depend on the BT device or Bluetooth stack of the device?

A user reported that those buttons continue to control the Windows Media Player in the background, so apparently WMP can capture those buttons and react to them even when is it is not active or does not have the focus. How can another application do the same? What is the API to use in order to capture those buttons?

[mm40]

I was just looking at the WM5 SDK help file bluetooth stuff, my guess is you have to open up a winsock connection to the stack and listen for the button changes to come in. It would be nice if windows forwarded them as WM_ messages. Otherwise you could use a Spy++ type program on the PPC if such a thing exists and see if the messages are being sent.

[The PocketTV Team]

It would be nice if windows forwarded them as WM_ messages.

Definitely.

If so much device-specific hacking must be done to capture those buttons (and nothing is standardized), it's probably not worth the trouble. And also it might depend on the BT stack in the device.

[Dan East]

open up a winsock connection to the stack

That will only work with the MS stack, which is the minority. I would assume the headset would expose a bluetooth service which interfaces the buttons.

Dan East

[The PocketTV Team]

open up a winsock connection to the stack

That will only work with the MS stack, which is the minority. I would assume the headset would expose a bluetooth service which interfaces the buttons.

is there a documentation on that (and on how to interface with it)?

[Dan East]

I'm sort of replying to your other thread here too (about the notification broker).

Probably the only way to pull off the level of control you require is to implement A2DP via both types of stacks within your app. You would search for and find headsets, connect to them, and stream the data yourself. That might solve your latency issue too, if the problem is on the PPC side.

Well, I would have to say it would be really, really tough to pull off. Try finding some sources dealing with A2DP. Keep in mind anything you implement will have to be done for both the MS and Widcomm bluetooth APIs, which are as different as they could be.

I don't know what type of service the headphones would expose for the buttons, or if perhaps that is included in A2DP.

Sorry, but I have zero experience when it comes to A2DP specifics, and can only provide the most rudimentary BT advice. In my case, I've implemented a PC based custom BT service (a crude TCP/IP proxy server) running on the MS stack, and a client end on the PPC supporting both MS and Widcomm stacks, that allows me to transfer data back and forth between the two. The PDA initiates the connection, and will iterate all BT devices and find one running my service, and make a connection if one is found.

So I don't have experience using any of the standardized BT services at all. I use the RFCOMM protocol (which is one of the few the MS stack supports), and am proprietary on both ends.

You can read my lamentations over the two BT APIs if you want more specifics on how they differ.

Dan East