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

[Tanu Kaskinen]

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.

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.

> > 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.

> 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.

-- 
Tanu

https://www.patreon.com/tanuk