Hi Mikel, On Tue, Nov 27, 2012 at 9:12 AM, Mikel Astiz <mikel.astiz.oss at gmail.com> wrote: > Hi Luiz, > > On Mon, Nov 26, 2012 at 9:17 PM, Luiz Augusto von Dentz > <luiz.dentz at gmail.com> wrote: >> Hi Mikel, >> >> On Mon, Nov 26, 2012 at 7:32 PM, Mikel Astiz <mikel.astiz.oss at gmail.com> wrote: >>> From: Mikel Astiz <mikel.astiz at bmw-carit.de> >>> >>> This patchset extends the previous patch (resent unmodified here) with the policy change suggested by Tanu. >>> >>> It seems no conclusion was reached about the names etc. but I believe this is the best alternative without the form factor and in any case the strings can easily be changed during/after pushing. >>> >>> Mikel Astiz (3): >>> bluetooth: Merge headset ports into one >>> bluetooth: Disable profile auto-switch policy for headsets >>> conf: Load bluetooth-policy module by default >>> >>> src/daemon/default.pa.in | 4 ++ >>> src/modules/bluetooth/module-bluetooth-device.c | 72 ++++++++++++++++++------- >>> src/modules/bluetooth/module-bluetooth-policy.c | 4 ++ >>> 3 files changed, 60 insertions(+), 20 deletions(-) >>> >>> -- >>> 1.7.11.7 >> >> >> I would like to see some good reasoning to do these changes, how we > > There was a long IRC discussion about this and the conclusion was that > introducing independent ports for A2DP and HSP/HFP headsets was a > regression (as first pointed out in [1]). There was no general > consensus but this seems the most strict interpretation of a port, > which represents a physical device no matter the underlying protocols. Im not sure I follow, my interpretation was that the ports were per sinks/sources just as the sinks and sources are per profiles otherwise they are pretty much useless for us which means the availability should be in the sinks/sources themselves to be able to generalize the policies regardless of the transports. >> gonna play out with port availability if we only have one that map for > > On how this affects Bluetooth, you are right that we now expose less > information in the port-availability. This was useful not only for > testing&debugging, but also to implement several policies in other > modules such as module-bluetooth-policy. The solution for the later > problem is to extend the API in bluetooth-util to expose the same > information. Well bluetooth API can be used for bluetooth only policy but if we really want to generalize this then there is no point. >> both profiles? What about if one of the profiles disconnects /became >> unavailable? Does that mean that all profiles has the same priority? > > Regarding the profile priorities, I'm not sure what you mean. The > card-profile priorities remain untouched, but obviously the > profile-port mapping has changed and therefore port priorities will > get affected. Do you see any problem with this? I asked this because I though the ports are an extension to the sinks/souces so we could express supported but not connected. -- Luiz Augusto von Dentz
