[pulseaudio-discuss] [PATCH] bluez5: Do not suspend on no -> unknown profile transitions
tanu.kaskinen at linux.intel.com
Fri Dec 19 02:38:22 PST 2014
On Fri, 2014-12-19 at 11:35 +0100, David Henningsson wrote:
> On 2014-12-19 10:55, Tanu Kaskinen wrote:
> > On Fri, 2014-12-19 at 10:24 +0100, David Henningsson wrote:
> >> @@ -1983,7 +1985,7 @@ static void handle_transport_state_change(struct userdata *u, struct pa_bluetoot
> >> /* Acquire or release transport as needed */
> >> acquire = (t->state == PA_BLUETOOTH_TRANSPORT_STATE_PLAYING && u->profile == t->profile);
> >> - release = (t->state != PA_BLUETOOTH_TRANSPORT_STATE_PLAYING && u->profile == t->profile);
> >> + release = (oldavail != PA_AVAILABLE_NO && t->state != PA_BLUETOOTH_TRANSPORT_STATE_PLAYING && u->profile == t->profile);
> > The profile availability and the transport state have 1:1 mapping, but
> > it's nevertheless (or perhaps precisely for that reason) ugly to mix the
> > two. I'd fix this by making the old transport state available in the
> > state change hook.
> > If you disagree, I don't care enough to block the patch on this issue.
> I admit it looks a bit ugly, but the alternative of creating some struct
> that just contains a transport pointer and an old transport state (just
> to use for the hook) seems equally ugly to me.
> Ok to push together with your module-card-restore patch?
> We could have a wider discussion on how we think about (and deal with)
> unavailable profiles for PulseAudio v7 or so.
Yes, please push!
More information about the pulseaudio-discuss