On Fri, 2017-03-10 at 21:22 +0100, Georg Chini wrote:
> Currently pressing the headset button is ignored. This patch sends a DBUS
> signal that can be caught by applications to trigger events like picking
> up or ending a phone call.
> ---
>
> No changes in v2
>
> src/modules/bluetooth/backend-native.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/src/modules/bluetooth/backend-native.c b/src/modules/bluetooth/backend-native.c
> index e6bf6fe..0eb530d 100644
> --- a/src/modules/bluetooth/backend-native.c
> +++ b/src/modules/bluetooth/backend-native.c
> @@ -51,6 +51,7 @@ struct transport_data {
> int sco_fd;
> pa_io_event *sco_io;
> pa_mainloop_api *mainloop;
> + pa_dbus_connection *connection;
> };
>
> #define BLUEZ_SERVICE "org.bluez"
> @@ -366,6 +367,9 @@ static void rfcomm_io_callback(pa_mainloop_api *io, pa_io_event *e, int fd, pa_i
> ssize_t len;
> int gain, dummy;
> bool do_reply = false;
> + struct transport_data *trd = t->userdata;
> + DBusMessage *msg;
> + dbus_uint32_t serial = 0;
I'd prefer to declare variables in the scope where they are used.
>
> len = pa_read(fd, buf, 511, NULL);
> if (len < 0) {
> @@ -394,8 +398,11 @@ static void rfcomm_io_callback(pa_mainloop_api *io, pa_io_event *e, int fd, pa_i
> t->microphone_gain = gain;
> pa_hook_fire(pa_bluetooth_discovery_hook(t->device->discovery, PA_BLUETOOTH_HOOK_TRANSPORT_MICROPHONE_GAIN_CHANGED), t);
> do_reply = true;
> - } else if (sscanf(buf, "AT+CKPD=%d", &dummy) == 1) {
> + } else if (sscanf(buf, "AT+CKPD=%d", &dummy) == 1 || sscanf(buf, "\r\nAT+CKPD=%d", &dummy) == 1) {
> do_reply = true;
> + msg = dbus_message_new_signal(t->device->path, "org.bluez.Headset", "ButtonPress");
> + if (msg)
> + dbus_connection_send(pa_dbus_connection_get(trd->connection), msg, &serial);
You can use pa_assert_se() with dbus_message_new_signal(). The function
can only fail on OOM.
Since you don't use the message serial, you can pass NULL to
dbus_connection_send().
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.
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.
--
Tanu
https://www.patreon.com/tanuk
