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@xxxxxxxxx> 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. 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. 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@xxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
