On Wednesday 18 December 2019 18:28:28 Pali Rohár wrote:
> On Wednesday 18 December 2019 11:00:07 Denis Kenzior wrote:
> > Hi Pali,
> > 
> > On 12/16/19 3:15 AM, Pali Rohár wrote:
> > > Hi!
> > > 
> > > On Monday 16 December 2019 00:11:04 Luiz Augusto von Dentz wrote:
> > > > Hi Pali,
> > > > 
> > > > On Thu, Dec 5, 2019 at 11:32 AM Pali Rohár <pali.rohar@gmail.com> wrote:
> > > > > 
> > > > > On Monday 02 December 2019 19:45:12 Pali Rohár wrote:
> > > > > > On Monday 02 December 2019 19:01:11 Tanu Kaskinen wrote:
> > > > > > > I think hsphfpd should be part of bluetoothd, but if that's not
> > > > > > > possible, then that's not possible.
> > > > > > 
> > > > > > I do not know if bluez developers are interested in having this code as
> > > > > > part of bluez project, specially when in bluez4 HFP profile was there
> > > > > > and in bluez5 was HFP code completely removed.
> > > > > 
> > > > > Hello, could someone from bluez developers comment this Tanu's point?
> > > > 
> > > > I would have to say no, we are definitely not interested in yet
> > > > another daemon for AT parsing, we actually have too many of these
> > > > around, either in a form of Modem Manager, oFono, etc.
> > > 
> > > Proposed hsphfpd daemon is not (only) for parsing AT commands, but for
> > > implementing logic around HSP and HFP profiles and export either native
> > > interfaces (linux uinput) or DBus interfaces for features provided by
> > > HSP and HFP specifications and also for current and future vendor
> > > extensions. And part of this HSP/HFP implementation is of course needed
> > > parsing and interpreting some of AT commands. Look into my design and
> > > API proposal. Current daemons which provides AT parsing (like ofono or
> > > modem manager) are not suitable for for whole HSP and HFP profiles with
> > > all those extensions (like all possible ways for reporting battery
> > > level), so for HFP is needed some of custom AT parser.
> > 
> > I'm not sure what logic around HSP you really care about.  It is just a
> > single button press in the end.
> 
> CSR features (battery status level, ...) and CSR codec selection (e.g.
> AuriStream). Also some apple extensions are used in HSP profile.
> 
> > For HFP, oFono can already support all sorts of extensions.  See for example
> > how we handled Siri for HFP support in oFono here:
> > https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/siri-api.txt.

About Siri: In hsphfpd API it is delegated to Telephony Agent. So
hsphfpd is not going to (re)implement it.

> I saw. But it does not support usage of vendor codecs, like CSR
> AuriStream and it does not support CSR extensions, like displaying text
> on embedded display.
> 
> > Many of the extensions you talked about are also relevant for real modems as
> > well (like battery reporting, call volume, etc).  Some of these APIs are
> > already defined in fact.
> > 
> > Given the above, oFono upstream has no interest in adding or maintaining
> > support this new framework.

Maybe better question: Do you mean that you do not want to maintain
hsphfpd, or that you completely do not want to see that ofono would be
"Telepony Agent" for hsphfpd?

> Denis, if you are not interested in my proposed hsphfpd daemon, how you
> want to solve problem with other extensions and other vendor codecs?
> 
> Also in my proposed solution it is possible to use HFP profile without
> Telephony Agent (ofono). Do you think it is really a good idea to have
> strong dependency on ofono just for bluetooth HFP headset?
> 
> 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.
> 
> There is a way to use ofono sim simulator which provide fake modem, but
> its setup is hard on desktop and it not automated.
> 
> So connecting bluetooth headset in HFP profile with ofono is something
> not so easy and not an obvious way.
> 

-- 
Pali Rohár
pali.rohar@gmail.com