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

[David Henningsson]

On 11/28/2012 03:25 PM, Luiz Augusto von Dentz wrote:
> Hi David,
>
> On Wed, Nov 28, 2012 at 12:14 PM, David Henningsson
> <david.henningsson at canonical.com> wrote:
>> On 11/27/2012 02:35 PM, Luiz Augusto von Dentz wrote:
>>>
>>> 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
>>
>>
>> This is no longer true - e g, on the ALSA side we have (since 1.0 or 2.0,
>> don't remember) shared ports for different profiles, e g, the "Analog
>> Output" port can be used with both a "Stereo" and a "5.1 Surround" profile.
>
> Still don't see the problem, why we cannot have multiple output ports
> per card? Or this is because they show up/are selectable in the Output
> tab, because that I would assume is a bug and only ports which belongs
> to the active profile should be listed there.

The premise for the UI work is that one port corresponds to one physical 
device, which corresponds to one entry in the UI.

This is the most user friendly IMO; a user might have speakers, 
headphones, hdmi outputs, which are all different ports, and the user 
does not have to worry whether the HDMI output belongs to the same card 
as the speaker output or not.

So one headset is one port (considering only output ports at this point).

When the user connects his HDMI output, the HDMI port is available, 
which means that it shows up in the GUI, regardless of whether the 
current active profile involves HDMI or not. Otherwise there would be no 
way to select HDMI at all.


-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic