On 12.03.2017 22:46, Tanu Kaskinen wrote: > On Sat, 2017-03-11 at 20:27 +0100, Georg Chini wrote: >>> I tried searching the net, and it looks like ButtonPress is not a >>> documented signal. Did you invent the signal yourself? If it's your >>> invention, I don't think the org.bluez.Headset interface should be >>> used. The org.bluez namespace should be controlled by the BlueZ >>> project. I would expect the dbus daemon to reject such signals anyway, >>> because pulseaudio hasn't been granted the right to send signals with >>> that interface on the system bus. >> It is an invented signal, but it is not rejected. > Okay. I checked now, and all signals seem to be accepted by default, so > I remembered the default dbus config wrong. > >> I did not know which >> name space to use, so I choose org.bluez because it is a bluez >> event. I don't mind using something else if you have a better idea. > I'd suggest org.PulseAudio.Bluetooth.Headset if we're going to do this. > > Attaching the pulseaudio card name to the signal could be useful too. > Maybe a string to variant dictionary for "extra information" would be > good? > > By the way, one thing I forgot to mention previously was that your code > lacked an unref call for the message. I'm not very familiar with the handling of D-Bus messages, so I did not know that. Thanks for the hint. > > Have you thought about button presses when A2DP is active? When I still > used a bluetooth headset with my phone, using the button to > pause/resume music playback was pretty handy. I don't know how that > works with bluez. Grepping for "button" in bluez source gives some > matches in avctp.c, so I guess AVCTP is somehow related. This is another button, at least on my head set. And it works. I don't know how, but at least audacious reacts to this button and also to the track forward/backward buttons. > >>> I'm a bit uncertain whether using D-Bus for this is the best option >>> anyway. If this is a new pulseaudio specific interface, the native >>> protocol might be a better choice. >>> >> I thought D-Bus is the right interface because bluez normally >> uses the D-Bus and pressing the headset button is a bluez event. > It's a bluetooth event, but I don't see how it's a bluez event. I meant bluetooth, not bluez. Bluetooth uses lots of D-Bus signals. > >> The reason for this patch was that I wrote an application to handle >> mobile phones and it was a nice feature to be able to use the button. >> I don't mind dropping that patch completely if you think it is out of >> scope for pulseaudio. > It's definitely not out of scope, because if pulseaudio is handling the > AT commands, how can any software ever take advantage of the button > functionality in bluetooth if pulseaudio doesn't somehow forward the > event? > > I'm torn between accepting or rejecting this approach. If we send a D- > Bus signal, that will be a completely separate mini-API that will have > to be supported forever. Also, I don't want to add APIs that provide > functionality that libpulse doesn't support. But on the other hand, if > I reject this now, we'll probably not have this nice feature any time > soon (unless you're willing to add it to the native protocol - and > that's not nearly as trivial as emitting a D-Bus signal). I'm leaning > towards rejecting this patch. > Well, as a developer I would look for this event rather on the D-Bus then in the native API because it is not directly sound related. From your response I am not quite sure if you are still considering to accept the approach or if I should remove the patch from patchwork.
