<div dir="ltr">Hi João Paulo,<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 2, 2013 at 4:10 PM, João Paulo Rechi Vita <span dir="ltr"><<a href="mailto:jprvita@gmail.com" target="_blank">jprvita@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Mar 27, 2013 at 1:11 PM, Mikel Astiz <<a href="mailto:mikel.astiz.oss@gmail.com">mikel.astiz.oss@gmail.com</a>> wrote:<br> > Hi João Paulo,<br> ><br> > On Wed, Mar 27, 2013 at 4:54 PM, João Paulo Rechi Vita<br> > <<a href="mailto:jprvita@gmail.com">jprvita@gmail.com</a>> wrote:<br> >> On Wed, Mar 27, 2013 at 5:20 AM, Mikel Astiz <<a href="mailto:mikel.astiz.oss@gmail.com">mikel.astiz.oss@gmail.com</a>> wrote:<br> >>> Hi João Paulo,<br> >>><br> >>> On Wed, Mar 27, 2013 at 6:16 AM, <<a href="mailto:jprvita@gmail.com">jprvita@gmail.com</a>> wrote:<br> >>>> From: João Paulo Rechi Vita <<a href="mailto:jprvita@openbossa.org">jprvita@openbossa.org</a>><br> >>>><br> >>>> ---<br> >>>> src/modules/bluetooth/bluetooth-util.c | 6 ++++++<br> >>>> src/modules/bluetooth/bluetooth-util.h | 1 +<br> >>>> 2 files changed, 7 insertions(+)<br> >>>><br> >>>> diff --git a/src/modules/bluetooth/bluetooth-util.c b/src/modules/bluetooth/bluetooth-util.c<br> >>>> index 2a4b694..59d0854 100644<br> >>>> --- a/src/modules/bluetooth/bluetooth-util.c<br> >>>> +++ b/src/modules/bluetooth/bluetooth-util.c<br> >>>> @@ -184,6 +184,8 @@ const char *pa_bt_profile_to_string(enum profile profile) {<br> >>>> return "hsp";<br> >>>> case PROFILE_HFGW:<br> >>>> return "hfgw";<br> >>>> + case PROFILE_HFP_AG:<br> >>>> + return "hfp_ag";<br> >>>> case PROFILE_OFF:<br> >>>> pa_assert_not_reached();<br> >>>> }<br> >>>> @@ -232,6 +234,10 @@ static void profile_to_remote_uuid(enum profile p, const char *res[2]) {<br> >>>> res[0] = HSP_AG_UUID;<br> >>>> res[1] = HFP_AG_UUID;<br> >>>> return;<br> >>>> + case PROFILE_HFP_AG:<br> >>>> + res[0] = HFP_AG_UUID;<br> >>>> + res[1] = NULL;<br> >>>> + return;<br> >>>> case PROFILE_OFF:<br> >>>> break;<br> >>>> }<br> >>>> diff --git a/src/modules/bluetooth/bluetooth-util.h b/src/modules/bluetooth/bluetooth-util.h<br> >>>> index 6423f88..28f63c8 100644<br> >>>> --- a/src/modules/bluetooth/bluetooth-util.h<br> >>>> +++ b/src/modules/bluetooth/bluetooth-util.h<br> >>>> @@ -62,6 +62,7 @@ enum profile {<br> >>>> PROFILE_A2DP_SOURCE,<br> >>>> PROFILE_HSP,<br> >>>> PROFILE_HFGW,<br> >>>> + PROFILE_HFP_AG,<br> >>>> PROFILE_OFF<br> >>>> };<br> >>>><br> >>>> --<br> >>>> 1.7.11.7<br> >>>><br> >>><br> >>> I don't see the need for such an additional profile, since we already have HFGW.<br> >>><br> >>> If you want to avoid associating the HSP UUID to this specific card<br> >>> profile, you need to handle that internally. Profiles are exposed<br> >>> outside the module and even in the UI, so we shouldn't change this<br> >>> unless strictly needed.<br> >>><br> >><br> >> I did it this way to be able to support HFP_HF implemented in oFono<br> >> without breaking support for HFP_HF implemented in BlueZ (pre external<br> ><br> > This is an internal problem that shouldn't affect the rest of the<br> > modules and the UI. You're already suffering this hassle in some of<br> > your patches, such as 24/24.<br> ><br> <br> </div></div>I don't think this is such a big deal. Modules (as in patch 24/24) are<br> part of PulseAudio, their versioning follows PulseAudio's versioning,<br> so this can be easily managed. Regading UIs, they shoudn't make<br> decisions based on hardcoded profile names. Do you have any concrete<br> example where this would break for you?<br></blockquote><div><br></div><div style>As I said before, I'm not concerned about renaming but about splitting. There's no need to add additional card profiles.</div><div style> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="im"><br> >> profiles support). Additionally, our profile naming scheme today is<br> >> imprecise, "a2dp" refers to A2DP Sink, "hsp" refers to both HSP HF and<br> >> HFP HF, HFGW refers to HFP AG. I think having one profile matching<br> >> each Bluetooth profile in a descriptive way would be much less<br> >> confusing for the end user. Ideally that would be: a2dp_source,<br> >> a2dp_sink, hsp_hs, hsp_ag, hfp_hf, hfp_ag, were the role part of the<br> >> name always refer to the role implemented by the remote device.<br> ><br> > We can discuss if the profiles should be renamed but this would be<br> > unrelated to this patch. In particular, I don't think the user cares<br> > about HSP vs HFP, so I'd be against splitting this.<br> ><br> <br> </div>But we will want to support HSP devices, specially bluetooth headsets<br> to be used with VoIP programs, and we don't want to depend on oFono<br> for that, so these need to be separate card profiles anyway. I suggest<br> we break this once and create the following profiles to accommodate<br> future extensions:<br> <br> enum profile {<br> PROFILE_A2DP_SINK,<br> PROFILE_A2DP_SOURCE,<br> PROFILE_HSP_HS,<br> PROFILE_HSP_GW,<br> PROFILE_HFP_HF,<br> PROFILE_HFP_GW,<br> PROFILE_OFF<br> <div class="HOEnZb"><div class="h5">}<br></div></div></blockquote><div><br></div><div style>I'm not following here. A simple bluetooth headset may support HSP or HFP equally.</div><div style><br></div><div style>Regarding the dependency to oFono, I think the original proposal was to depend on oFono for both HSP and HFP, as well as for both roles (HS and GW).</div> <div style><br></div><div style>In any case, the user is not interested in the difference between HSP and HFP.</div><div style><br></div><div style>Cheers,</div><div style>Mikel</div></div></div></div>