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.
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.
James
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
