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

[Luiz Augusto von Dentz]

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