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

Georg Chini georg at chini.tk
Thu Mar 30 05:51:27 UTC 2017

On 13.03.2017 17:25, Tanu Kaskinen wrote:
> On Mon, 2017-03-13 at 09:36 +0100, Georg Chini wrote:
>> On 12.03.2017 22:46, Tanu Kaskinen wrote:
>>> On Sat, 2017-03-11 at 20:27 +0100, Georg Chini wrote:
>>>> 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.
> I removed it from patchwork now.
Hi Tanu,

could you please outline how it would be done using the native API?
I don't know how to send notifications through the native API and
also the event can happen without any client connected. The event
could however trigger a client connection for example when you
want to pick up a phone call using the button. I do not see how the
native API can handle that case at all.



More information about the pulseaudio-discuss mailing list