On Tue, 2014-02-04 at 19:04 -0300, jprvita at gmail.com wrote:
> From: Jo?o Paulo Rechi Vita <jprvita at openbossa.org>
>
> ---
> src/modules/bluetooth/module-bluez5-device.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/src/modules/bluetooth/module-bluez5-device.c b/src/modules/bluetooth/module-bluez5-device.c
> index e48eaa9..52a5c68 100644
> --- a/src/modules/bluetooth/module-bluez5-device.c
> +++ b/src/modules/bluetooth/module-bluez5-device.c
> @@ -1992,6 +1992,7 @@ static pa_hook_result_t transport_state_changed_cb(pa_bluetooth_discovery *y, pa
> /* Run from main thread context */
> static int device_process_msg(pa_msgobject *obj, int code, void *data, int64_t offset, pa_memchunk *chunk) {
> struct bluetooth_msg *m = BLUETOOTH_MSG(obj);
> + struct userdata *u = m->card->userdata;
>
> switch (code) {
> case BLUETOOTH_MESSAGE_IO_THREAD_FAILED:
> @@ -2002,6 +2003,10 @@ static int device_process_msg(pa_msgobject *obj, int code, void *data, int64_t o
> pa_assert_se(pa_card_set_profile(m->card, pa_hashmap_get(m->card->profiles, "off"), false) >= 0);
> break;
> case BLUETOOTH_MESSAGE_STREAM_FD_HUP:
> + if (u->transport->profile == PA_BLUETOOTH_PROFILE_HEADSET_AUDIO_GATEWAY) {
> + pa_source_suspend(u->source, true, PA_SUSPEND_USER);
> + pa_sink_suspend(u->sink, true, PA_SUSPEND_USER);
> + }
Would it make more sense to set the transport state to IDLE, and let the
normal transport state transition take care of suspending the sink and
source? And is this really specific to the gateway profile? Why
shouldn't we suspend the sink and source with any profile if the remote
end hangs up the socket?
--
Tanu
