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