[pulseaudio-discuss] [PATCH v5 1/4] bluetooth: use consistent profile names
georg at chini.tk
Mon Sep 25 13:49:20 UTC 2017
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_HEADSET_AUDIO_GATEWAY ->
>>> Signed-off-by: James Bottomley <James.Bottomley at HansenPartnership.c
>> It looks to me like the conversion is not completely correct. In
>> the native backend (in your notation) currently implements
>> while the ofono backend implements
> 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,
>> 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
> 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
After introducing PA_BLUETOOTH_PROFILE_HFP_HF, it should then
be also used in the ofono backend.
More information about the pulseaudio-discuss