[pulseaudio-discuss] [PATCH v2 2/3] bluetooth: separate HSP and HFP

[Tanu Kaskinen]

On Sat, 2016-08-20 at 15:03 -0700, James Bottomley wrote:
> When all headsets supported both HSP and HFP, life was good and we
> only needed to implement HSP in the native backend.  Unfortunately
> some headsets have started supporting HFP only.  Unfortuantely, we
> can't simply switch to HFP only because that might break older HSP
> only headsets meaning we need to support both HSP and HFP separately.
> 
> This patch separates them from a joint profile to being two separate
> ones.  The older one retains the headset_head_unit name, meaning any
> saved parameters will still select this (keeping us backward
> compatible).  It also introduces a new headset_handsfree.
> 
> For headsets that support both HSP and HFP, the two profiles will
> become separately visible and selectable.  This will only matter once
> we start adding features to HFP that HSP can't support (like wideband
> audio).
> 
> Signed-off-by: <James.Bottomley at HansenPartnership.com>

One thing that needs fixing is the profile waiting logic - we wait
until all supported profiles are connected (or until a timeout expires)
before loading module-bluez5-device. Since we will now connect only HFP
or HSP, it doesn't make sense to wait for both of them getting
connected. The waiting logic is implemented in
pa_bluetooth_transport_set_state().

> --- a/src/modules/bluetooth/bluez5-util.c
> +++ b/src/modules/bluetooth/bluez5-util.c
> @@ -76,6 +76,8 @@
>      "
> </interface>"                                                     \
>      "</node>"
>  
> +bool disable_profile_hfp = false;

Global bluetooth stuff should go to the pa_bluetooth_discovery struct.
module-bluez5-discover should pass the value from the module argument
to pa_bluetooth_discovery_get(). module-bluez5-device doesn't need a
module argument, it can read it from the pa_bluetooth_discovery object
(a new getter function is needed for that).

>  static const char* const valid_modargs[] = {
>      "path",
> +    "disable_profile_hfp",

We try to avoid negative option names on the basis that double
negatives are not nice ("disable_foo=no"), so I'd prefer
"enable_profile_hfp".

-- 
Tanu