Hi Jo?o Paulo,
On Wed, Mar 27, 2013 at 4:54 PM, Jo?o Paulo Rechi Vita
<jprvita at gmail.com> wrote:
> On Wed, Mar 27, 2013 at 5:20 AM, Mikel Astiz <mikel.astiz.oss at gmail.com> wrote:
>> Hi Jo?o Paulo,
>>
>> On Wed, Mar 27, 2013 at 6:16 AM, <jprvita at gmail.com> wrote:
>>> From: Jo?o Paulo Rechi Vita <jprvita at openbossa.org>
>>>
>>> ---
>>> src/modules/bluetooth/bluetooth-util.c | 6 ++++++
>>> src/modules/bluetooth/bluetooth-util.h | 1 +
>>> 2 files changed, 7 insertions(+)
>>>
>>> diff --git a/src/modules/bluetooth/bluetooth-util.c b/src/modules/bluetooth/bluetooth-util.c
>>> index 2a4b694..59d0854 100644
>>> --- a/src/modules/bluetooth/bluetooth-util.c
>>> +++ b/src/modules/bluetooth/bluetooth-util.c
>>> @@ -184,6 +184,8 @@ const char *pa_bt_profile_to_string(enum profile profile) {
>>> return "hsp";
>>> case PROFILE_HFGW:
>>> return "hfgw";
>>> + case PROFILE_HFP_AG:
>>> + return "hfp_ag";
>>> case PROFILE_OFF:
>>> pa_assert_not_reached();
>>> }
>>> @@ -232,6 +234,10 @@ static void profile_to_remote_uuid(enum profile p, const char *res[2]) {
>>> res[0] = HSP_AG_UUID;
>>> res[1] = HFP_AG_UUID;
>>> return;
>>> + case PROFILE_HFP_AG:
>>> + res[0] = HFP_AG_UUID;
>>> + res[1] = NULL;
>>> + return;
>>> case PROFILE_OFF:
>>> break;
>>> }
>>> diff --git a/src/modules/bluetooth/bluetooth-util.h b/src/modules/bluetooth/bluetooth-util.h
>>> index 6423f88..28f63c8 100644
>>> --- a/src/modules/bluetooth/bluetooth-util.h
>>> +++ b/src/modules/bluetooth/bluetooth-util.h
>>> @@ -62,6 +62,7 @@ enum profile {
>>> PROFILE_A2DP_SOURCE,
>>> PROFILE_HSP,
>>> PROFILE_HFGW,
>>> + PROFILE_HFP_AG,
>>> PROFILE_OFF
>>> };
>>>
>>> --
>>> 1.7.11.7
>>>
>>
>> I don't see the need for such an additional profile, since we already have HFGW.
>>
>> If you want to avoid associating the HSP UUID to this specific card
>> profile, you need to handle that internally. Profiles are exposed
>> outside the module and even in the UI, so we shouldn't change this
>> unless strictly needed.
>>
>
> I did it this way to be able to support HFP_HF implemented in oFono
> without breaking support for HFP_HF implemented in BlueZ (pre external
This is an internal problem that shouldn't affect the rest of the
modules and the UI. You're already suffering this hassle in some of
your patches, such as 24/24.
> profiles support). Additionally, our profile naming scheme today is
> imprecise, "a2dp" refers to A2DP Sink, "hsp" refers to both HSP HF and
> HFP HF, HFGW refers to HFP AG. I think having one profile matching
> each Bluetooth profile in a descriptive way would be much less
> confusing for the end user. Ideally that would be: a2dp_source,
> a2dp_sink, hsp_hs, hsp_ag, hfp_hf, hfp_ag, were the role part of the
> name always refer to the role implemented by the remote device.
We can discuss if the profiles should be renamed but this would be
unrelated to this patch. In particular, I don't think the user cares
about HSP vs HFP, so I'd be against splitting this.
Cheers,
Mikel
