On Thu, 2012-11-29 at 14:28 +0100, Mikel Astiz wrote:
> From: Mikel Astiz <mikel.astiz at bmw-carit.de>
>
> When a headset is having a profile switch, we can either leave the
> SCO state unmodified (as it was before this patch) or we can
> alternatively request it (as older versions of PA).
>
> This patch tries to avoid a potential regression in case a module
> such as module-suspend-on-idle is not present, due to the provided
> resume-on-running policy. Without this patch, and without such a policy,
> the sink and sources would stay suspended until the user manually
> changed the suspend state.
The last sentence is incorrect, the situation is worse than that. If the
suspend cause is IDLE, there's no way for the user to unsuspend the
device, because the user can only control the USER suspend cause.
>
> A more sophisticated solution to this problem would be to revert this
> patch and implement the resume-on-running policy inside
> module-bluetooth-policy.
> ---
> src/modules/bluetooth/module-bluetooth-device.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/src/modules/bluetooth/module-bluetooth-device.c b/src/modules/bluetooth/module-bluetooth-device.c
> index d1c386f..66f00e0 100644
> --- a/src/modules/bluetooth/module-bluetooth-device.c
> +++ b/src/modules/bluetooth/module-bluetooth-device.c
> @@ -2010,7 +2010,10 @@ static int setup_transport(struct userdata *u) {
> u->transport_removed_slot = pa_hook_connect(&t->hooks[PA_BLUETOOTH_TRANSPORT_HOOK_REMOVED], PA_HOOK_NORMAL,
> (pa_hook_cb_t) transport_removed_cb, u);
>
> - bt_transport_acquire(u, FALSE);
> + if (u->profile == PROFILE_HSP || u->profile == PROFILE_A2DP)
> + bt_transport_acquire(u, TRUE);
> + else
> + bt_transport_acquire(u, FALSE);
>
> bt_transport_config(u);
Shouldn't the "data.suspend_cause = PA_SUSPEND_IDLE" assignment be
removed from add_sink()? The problem that we're fixing is that if the
device gets into the IDLE state, it's hosed if module-suspend-on-idle
isn't loaded. Therefore, setting the suspend cause to IDLE makes no
sense.
I guess the change done in this patch makes sense anyway. What if
bt_transport_acquire() fails, shouldn't setup_transport() return an
error in that case?
--
Tanu
