Hi Pali,
Yes, I see. Also there are devices without HFP support, only with HSP.
pulseaudio support also these devices and pulseaudio is not going to
drop support for them. Last time when I looked at ofono, it has no HSP
support. Is ofono going to add support for HSP?
No.
<snip>
But would you accept patches which exports DBus API e.g. for displaying text
on HFP headset with embedded display? Or patches which implements 3
different way for reporting battery level status of HFP headset? And API
for sending "computer battery level" to HFP headset? Or implementing
setup of SCO sockets (via RFCOMM layer) for custom codecs? Or exporting
uinput linux device for button press events? Because all these
So which roles are we talking about here? Your Design document shows
hsphfpd registering for both HFP AG and HFP HF roles, but maybe this was
not the intent?
If you're talking about extending oFono APIs when it is acting as the HF
connecting to the AG, then codec setup APIs, etc are definitely
something that would be welcome.
If you're talking about AG role, then that is different... In general,
if the oFono is in an AG role, then there should be nothing to configure
and there are no APIs for this role. Things like reporting AG battery
level to HFP headset are done directly using plugins. See
ofono_emulator_set_indicator and how this is done by upower.c for
example. I happily take patches for any additional features (codecs,
etc) you want to support here.
But... oFono upstream has no interest in accepting forwarded AT commands
from some external daemon if we're in AG role. We rejected such a
design years ago and nothing has changed.
AG role is already quite tricky to implement without additional
complexity introduced by having multiple applications and IPC. "Its
your funeral" as the saying goes if you want to go that route.
<snip>
I disagree here. Primary purpose of HFP for desktop users is ability to
use bluetooth's microphone. And not telephony stack and its complicated
features like call hold and others, which are in HFP used and
implemented probably only in car kits.
So your primary goal here is to have the desktop play the role of the
AG, purely so you can forward the audio from a headset out to whatever
it is that you want. And you want oFono (or some other daemon) to
(optionally) handle the call related AT commands in the HFP AG role.
Such a design will get a NAK from me on the oFono side. But don't let
that stop you. You can simply invoke oFono APIs directly from your
daemon. No need for any changes in oFono itself. As mentioned above, I
wouldn't recommend it, but... :)
Also for using ofono with HFP profile is not possible on desktop
computer which do not have any modem as it is hooked to some active
modem.
This statement is not true at all. You can use oFono without any 'real'
modems attached. It can happily manage only HFP devices (or modems as we
call them.)
Ok, can you please provide exact steps how to do it, including
activating of bidirectional audio stream?
So again, which role? If we're the HF connecting to the AG, then things
just work without a modem. If we're the AG, then yes you need a modem
to be driven by the AG connection.
You must be thinking of the oFono HFP AG implementation...
Yes! For connecting bluetooth headset you need HFP AG implementation.
And I guess this is the reason why simulator is needed. HFP headset acts
as a "client" for modem. Therefore on desktop / laptop you need to
implement "modem server" which will be used by HFP headset "client".
And phone simulator is doing exactly this "modem server", it is
simulator of modem.
Okay, I see now. Yes, the above is correct. My comments about not
needing a modem device hold true only if oFono is in HFP HF role
connecting to an AG.
Regards,
-Denis
