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