[pulseaudio-discuss] [PATCH v0 0/2] bluetooth: Port->profile association

[Mikel Astiz]

Hi David,

On Tue, May 21, 2013 at 2:37 PM, David Henningsson
<david.henningsson at canonical.com> wrote:
> On 05/20/2013 11:48 AM, Mikel Astiz wrote:
>>
>> From: Mikel Astiz <mikel.astiz at bmw-carit.de>
>>
>> These patches address a regression existing in the master branch, which
>> specially affects the gnome UI. More info in
>> https://bugs.freedesktop.org/show_bug.cgi?id=64713.
>
>
> Thanks, I have now tested them and confirmed that they solve the problem
> here!
>
>
>> The proposed solution is fairly simple but triggers the question whether
>> something like PA_CORE_HOOK_PORT_PROFILE_ADDED is needed in the case of late
>> Bluetooth UUIDs. In this scenario, the port has already been created by the
>> time a new profile needs to be registered, typically after a
>> Bluetooth-pairing procedure (for reference, see
>> d4368aa608b79f58a279018eb74abd5a6bff30ac).
>
>
> I'm not really familiar with the late UUID problem, how common is that
> really? I have never seen it myself, but then my range of hardware is
> limited to a simple headset and a laptop.

It's fairly common when pairing phones but I've never seen it with
headsets. In practice, I'd say it's hardly possible to hit this issue
when the pairing procedure (the Bluetooth device discovery) is
initiated from our side, which is the case for all headsets.

Besides, obviously, it's only possible with devices that support
multiple profiles (HSP/HFP + A2DP).

>
>
>> This patchset ignores such possible issue and simply modifies the port's
>> profile hashmap without triggering any event.
>
>
> As long as a card change subscription event is sent after both the new
> profile is added and the port->profile hashmap is updated, we should be fine
> w r t clients.
> (Except that no clients actually support new profiles AFAIK...)
>
> Similarly, right now I think we're fine with the existing
> PA_CORE_HOOK_CARD_PROFILE_ADDED hook (which I assume is correctly fired?),

Yes, this hook should be correctly fired.

> that could trigger that the port->profile hashmap might have been updated
> too. If we in the future need to add a separate per-port hook to tell that
> the profile hashmap has changed, we can add it later.
>

Sounds good to me.

Cheers,
Mikel