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? > 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. 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. James