[pulseaudio-discuss] [PATCH 2/2, v2] backend-native: send DBus signal on headset button press

[Georg Chini]

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.