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.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
