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. -- Tanu https://www.patreon.com/tanuk
