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
