[pulseaudio-discuss] [PATCH v1 0/3] bluetooth: Headset port availability

[Mikel Astiz]

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.

> 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.

> 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?

Cheers,
Mikel

[1] http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-November/015402.html