On Mon, 2017-03-13 at 09:48 +0100, Georg Chini wrote:
> With headset=auto it is possible that AG devices are connected and handled
> via the native backend when ofono is started. Because the HS role will then
> be disabled in the native backend, AG devices must be disconnected and any
> future connections will be handled by ofono.
This seems racy, although there's probably no better solution, short of
designing a new sco socket handover protocol between pulseaudio and
ofono. If ofono tries to start listening for incoming sco connections
before our sco socket is closed, will things break?
> ---
> src/modules/bluetooth/bluez5-util.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> diff --git a/src/modules/bluetooth/bluez5-util.c b/src/modules/bluetooth/bluez5-util.c
> index 8d59b6b..394f3a7 100644
> --- a/src/modules/bluetooth/bluez5-util.c
> +++ b/src/modules/bluetooth/bluez5-util.c
> @@ -982,6 +982,23 @@ void pa_bluetooth_discovery_set_ofono_running(pa_bluetooth_discovery *y, bool is
> if (y->headset_backend != HEADSET_BACKEND_AUTO)
> return;
>
> + /* If ofono starts running, all devices that might be connected to the HS role
> + * need to be disconnected, so that the devices can be handled by ofono */
> + if (is_running) {
> + void *state;
> + pa_bluetooth_device *d;
> +
> + PA_HASHMAP_FOREACH(d, y->devices, state) {
> + if(device_supports_profile(d, PA_BLUETOOTH_PROFILE_HEADSET_AUDIO_GATEWAY)) {
Space missing after "if".
> + DBusMessage *m;
The indentation is a bit off.
> +
> + pa_assert_se(m = dbus_message_new_method_call(BLUEZ_SERVICE, d->path, "org.bluez.Device1", "Disconnect"));
> + dbus_connection_send(pa_dbus_connection_get(y->connection), m, NULL);
> + dbus_message_unref(m);
It would be good to use dbus_message_set_no_reply() when you're not
interested in the method call reply.
--
Tanu
https://www.patreon.com/tanuk
