Hi Tanu, On Fri, Nov 23, 2012 at 8:26 PM, Tanu Kaskinen <tanuk at iki.fi> wrote: > On Fri, 2012-11-23 at 13:41 +0100, Mikel Astiz wrote: >> From: Mikel Astiz <mikel.astiz at bmw-carit.de> >> >> Merge the former "hsp-output" and "a2dp-output" ports into one single >> port, in order to fix the regression of having several independent >> entries in the UI. > > I'm not sure if this is anything serious, but with this change, I think > (I haven't actually tested) module-bluetooth-policy works with headsets > that support both profiles as follows, not very smartly: > > - It never does anything until both profiles enter the "playing" state. That was not the intention. The patch should set the port to PORT_AVAILABLE_YES if *any* of the two profiles is set, and thus the port switch could be triggered. > I'm not sure if this scenario is possible. Can headsets initiate the > "playing" state for one profile while the other profile is already > "playing" too? It's very unlikely, I haven't seen that yet. > > - If both profiles enter the "playing" state, then semi-randomly one or > the other will be activated. As stated above, this will happen if any of the two profiles starts playing *and* the active profile is "off". But you're right, the activated profile will be semi-random, i.e. the policy is not very smart. I can't think of any workaround to this problem once the ports get merged, since module-bluetooth-policy is not able to distinguish the state of each Bluetooth profile. > To me it looks like this is not serious, so this is not a blocker issue > for accepting the patch. > Cheers, Mikel