On 21.09.2017 06:45, James Bottomley wrote:
On Thu, 2017-09-21 at 06:27 +0200, Georg Chini wrote:
On 20.09.2017 23:12, James Bottomley wrote:
On Wed, 2017-09-20 at 20:41 +0200, Georg Chini wrote:
On 20.09.2017 20:10, James Bottomley wrote:
On Wed, 2017-09-20 at 18:11 +0200, Georg Chini wrote:
On 20.09.2017 01:27, James Bottomley wrote:
This is round 4 of the initial bluetooth: separate HSP and
HFP patch.
It includes the review feedback and a global on/off
switch just in case there's a problem headset with dual
HFP/HSP but non-working HFP. This one now includes a
proper rfcomm negotiation (see patch 3). I've finally
figured out a bug in the rfcomm negotiation that was
causing issues with my LG 900 headset, so I think it's now
working for everything (but testing would be welcome).
James Bottomley (3):
bluetooth: use consistent profile names
bluetooth: separate HSP and HFP
bluetooth: add correct HFP rfcomm negotiation
src/modules/bluetooth/backend-native.c | 168
+++++++++++++++++++++---
src/modules/bluetooth/backend-ofono.c | 4
+-
src/modules/bluetooth/bluez5-util.c | 46
+++++--
src/modules/bluetooth/bluez5-util.h | 10
+-
src/modules/bluetooth/module-bluetooth-policy.c | 3
+-
src/modules/bluetooth/module-bluez5-device.c | 102
++++++++++----
src/modules/bluetooth/module-bluez5-discover.c | 6
+-
7 files changed, 274 insertions(+), 65 deletions(-)
Hello James,
thank you for continuing your work. Unfortunately your patch
set collides with running ofono. Currently, with the default
of "headest=auto", the native and the ofono backends are
active in parallel. This is possible because ofono only
supports HFP while PA only supports HSP.
If PA starts supporting HFP headsets, this breaks above
assumption and ofono and PA both try to register the
corresponding HFP UUID.
To work around the problem, I suggest to disable native HFP
support if headset_backend == HEADSET_BACKEND_AUTO, unless
configured otherwise on the command line.
Actually, Pulseaudio already includes an ofono is running
check, so the enable should be set to no for backend ofono or
backend auto and ofono running, which would enable it in the
widest possible set of scenarios.
I can cook up a patch for that, hang on.
James
This does only work for the special case when PA acts in the
HSP headset role. In this case, no duplicate UUIDs are registered
and disabling the profile only needs to be done because otherwise
PA and ofono would both be listening for incoming SCO
connections.
It seems to me that pulse checks the dbus connection to ofono
before deciding on the backend (and therefore deciding what to
register), so as long as pulse finds ofono running, there won't be
any duplicate registrations.
The case here is different in that a duplicate UUID is
registered. This means, by the time PA recognizes that ofono is
running, ofono already tried to register the UUID and failed.
That's why you have to disable HFP even if ofono is currently not
running.
I don't think that can be true if ofono is already running, can it?
Either ofono registered the HFP UUIDs way earlier or pulse sees
ofono isn't running and registers them.
I don't think requiring the ofono daemon to be running before
pulseaudio is insurmountable. On my openSUSE system, ofono is
started from systemd and pulse from user login, so this is
automatically satisfied. I think where pulse is used in system
mode, you just have to tell systemd to start ofono first, which is
certainly doable.
I don't think it is a good idea to rely on the order ofono and pulse
are started. Also. if pulse is running and has already registered
the UUID, what will happen if ofono starts? ofono has no checks
for pulse and will simply try to register the UUID. I fear that this
happens before pulse recognizes that ofono is running.
This is an initialisation issue for how you want everything to work.
The current distro setup is ofono from systemd and pulse from login,
so I can't actually see what the problem is ... unless there's some
reason why what the distros are doing is wrong?
If pulse is already running when you start ofono, that's caveat emptor
... plus, as far as I can tell, it still all works because ofono
doesn't seem to get the uuid.
The point is to get a working default configuration the distros can
use. That means that we need a good way of distinguishing the non-
ofono case for backend = auto. Ofono not running seems to be the
definitive test unless there's another you can propose?
People may start/stop ofono/PA manually (or PA may crash
and be re-spawned). The main point is that currently there is
no restriction on the order you start things and your patch set
should not introduce it.
But maybe using the same approach like for the HSP headset
role of PA works if PA sees ofono before ofono tries to register
the UUID. I guess the best idea is to test what happens.
The current fly in the ointment is that for a dual HFP/HSP device,
we need to fall back to the HSP profile not simply disable the HFP
one, which requires extra jiggerypokery.
No, you don't need to fall back to HSP. The HFP connection will
be handled by ofono in that case.
Well, yes you do. There's no current easy way to use HFP_HF with
ofono, so you want the HSP profile to be exposed if it exists, so
there's an easy connection to the headset.
If ofono exposes HFP, you won't get your headset to connect to HSP, even
if the device supports both, unless you could switch off HFP on the device
side. Since PA 11.0 HFP_HF is working quite well with ofono, though it is
clumsy to set up. And if you run ofono you might want headset support
through ofono because ofono enables the HFP control features which
PA cannot support.
My suggestion was to disable HFP in "headset=auto" mode only if you
don't overwrite it on the command line. If you run ofono with
--noplugin=hfp_ag_bluez5 and enable HFP support in PA explicitly,
you will still have HFP headset support through PA if you want it, only
the default would be to go through ofono like it is now. I think you should
have the choice of three options:
1) No ofono at all, everything goes through the native backend
2) HFP_HF support through PA, HFP_AG support through ofono
3) HFP_HF and HFP_AG support through ofono
Regards
Georg
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
