On 28.04.20 21:06, Pali Rohár wrote:
On Tuesday 28 April 2020 20:50:33 Georg Chini wrote:
Personally I don't see a problem to remove the AG role support from
the ofono backend because nobody uses it. What I proposed earlier
- allow hsphfpd to disable the HFP HS role and keep a "legacy" ofono
backend for the HFP HS role - should not be that hard to implement
compared to all the time and work you already invested and it would
help us to keep users happy.
As I said, I have no problems with allowing to disable particular
profile from hsphpfd. But the way how ofono has it implemented, when it
is not possible to unregister specific profile and it always register
master SCO listening socket, it means that you cannot have two
applications which would implement or register HSP or HFP profile for
audio, independently of the role.
So you cannot use ofono's HFP AG role for connecting mobile phone and
other application (e.g. hsphpfd) for using HFP HS role for connecting
headset.
Sorry, forgive my ignorance. You can switch off ofonos AG role,
in that case it will only register the HS role with bluetoothd and
only react to connection attempts with the specific UUID.
Is it not possible that ofono registers one role and hsphfpd the
other?
And even if it is not possible and you can't use both at the same
time (which would be a pity), we still have to respect if a user
thinks that for him a working implementation for his mobile is
more important than good headset support and therefore prefers
the ofono backend over any other backend.
So what you want is currently impossible. You have to first fix ofono
daemon, design and export API for it and then implement other side to
use that API.
And I'm explaining again that this is reason why to have one central
daemon which would implement HSP and HFP profiles and proxies needed
support / sockets to target applications.
If one application is stealing listening sockets and cannot be
configured to not do it, other applications are just out of luck.
It is same as if two UDP or TCP applications wants to listen on port
1234 and both want to accept new connections. Without full cooperative
environment it does not work. hsphfpd daemon is there to accept new
connections from both RFCOMM and SCO sockets and do all needed stuff
with it (pass to other application, or process data on it directly).
The point is, that the applications that support the new hsphfpd
not yet exist, so we have at least to support the status quo until
there is some alternative.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
