On 25.09.2017 15:31, James Bottomley wrote: > On Sun, 2017-09-24 at 15:07 +0200, Georg Chini wrote: >> On 21.09.2017 21:26, James Bottomley wrote: >>> The PA_BLUETOOTH_PROFILE names should mirror the PA_BLUETOOTH_UUID >>> names using profile_function instead of randomly made up >>> names.  Fix >>> this with the transformation: >>> >>> PA_BLUETOOTH_PROFILE_HEADSET_HEAD_UNIT -> >>> PA_BLUETOOTH_PROFILE_HSP_HS >>> PA_BLUETOOTH_PROFILE_HEADSET_AUDIO_GATEWAY -> >>> PA_BLUETOOTH_PROFILE_HFP_AG >>> >>> Signed-off-by: James Bottomley <James.Bottomley at HansenPartnership.c >>> om> >>> >> It looks to me like the conversion is not completely correct. In >> fact, >> the native backend (in your notation) currently implements >> >> PA_BLUETOOTH_PROFILE_HSP_HS >> PA_BLUETOOTH_PROFILE_HSP_AG >> >> while the ofono backend implements >> >> PA_BLUETOOTH_PROFILE_HFP_HF >> PA_BLUETOOTH_PROFILE_HFP_AG > So your problem is that the current ofono backend actually > uses PA_BLUETOOTH_PROFILE_HEADSET_HEAD_UNIT which gets translated to > PA_BLUETOOTH_PROFILE_HSP_HS but you think that's a bug in the current > code because it should be HFP instead? I would not call it a bug. It just would be nice when in the end all the names would be correct. It is a bit strange to have PA_BLUETOOTH_PROFILE_HSP_HS in the ofono backend when it actually implements PA_BLUETOOTH_PROFILE_HFP_HF. The same applies for the AG role and the native backend. The native backend implements PA_BLUETOOTH_PROFILE_HSP_AG, not HFP. > >> Would it collide with your later patches to distinguish between the >> different roles/profiles already in your first patch? As far as I can >> see, the real separation of HSP/HFP is mainly done in the native >> backend. > Well, yes, because this patch is designed as an obvious constant rename > which is easy to review.  If I start adding logic changes, it defeats > the purpose of the patch being a simple rename. I understand the purpose to keep it simple. Maybe you could just split the two AG roles in that patch and add a remark in the commit message that you will do the separation of the HS/HF role in the next patch? This would still require some code changes but they would be minimal. > > Before the patch that follows this, there is no equivalent > of PA_BLUETOOTH_PROFILE_HFP_HF, so I don't really want to introduce one > here before I add the patch that gives it meaning.  I agree this > profile should already have existed in the ofono backend, but it > doesn't. After introducing PA_BLUETOOTH_PROFILE_HFP_HF, it should then be also used in the ofono backend. > > James