[PATCH v5 1/4] bluetooth: use consistent profile names

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2017-09-25 at 15:49 +0200, Georg Chini wrote:
> 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.com>
> > > > 
> > > 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.

I really think, if this has to be done, it should be done as a separate
patch to keep this patch simple and obvious.  Even better, why don't
you decide what should happen to ofono and send the patch to the list.
 I can keep it in this series under your authorship if necessary, that
way it would be applied when this series is?

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

So right at the moment, I believe from the logic that ofono will
continue to work as it does today even with these patches applied.  My
problem with making any changes to the ofono backend is that I've never
been able to get it working, so I have no means of testing it.  Since
you have it all working, could you test out the changes you want and
send them yourself?  That way there'd be no cockups.

Regards,

James



[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux