From: Denis Kenzior <denkenz@gmail.com> To: "Pali Rohár" <pali.rohar@gmail.com> Cc: Luiz Augusto von Dentz <luiz.dentz@gmail.com>, "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>, Tanu Kaskinen <tanuk@iki.fi>, General PulseAudio Discussion <pulseaudio-discuss@lists.freedesktop.org>, ofono@ofono.org, devkit-devel@lists.freedesktop.org, Bastien Nocera <hadess@hadess.net>, Georg Chini <georg@chini.tk>, Russell Treleaven <rtreleaven@bunnykick.ca>, Arun Raghavan <arun@arunraghavan.net>, Marcel Holtmann <marcel@holtmann.org>, Sebastian Reichel <sre@ring0.de>, Pavel Machek <pavel@ucw.cz> Subject: Re: [pulseaudio-discuss] Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux Date: Thu, 19 Dec 2019 08:53:54 -0600 [thread overview] Message-ID: <90261b42-1048-370f-7680-acd9f7e754ed@gmail.com> (raw) In-Reply-To: <20191219095132.blj3oyyrlfowv5ik@pali> Hi Pali, >>> 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? > > My proposed hsphfpd is going to support both roles. Which means to > implement whole HFP profile. So for connecting bluetooth headsets (when > AG role is needed on desktop) and also for connecting mobile phones > (when HF role is needed on desktop). > > And my primary motivation is for bluetooth headsets as this is what are > asking desktop and laptop users again and again that is missing on Linux > systems. > > So higher priority has AG role and slightly lower priority has HF role. > So to summarize. You have broadly 3 main use cases for HFP: 1. HF connecting to AG role. Essentially a carkit role. oFono does this pretty well already and has the APIs defined that cover up to HFP 1.7. Any vendor extensions can be easily added. And some carkit manufacturers already use it. 2. AG role when you have a 'real modem' behind it. oFono already provides everything needed for this scenario. 3. AG role when you don't have a real modem or you have some sort of VoIP use case. oFono doesn't cover this case as you stated. So I can see value in something that implements case #3. But having said that, oFono will not be receiving AT commands from external daemons: - For case 1, it'd just be a rehash of what oFono does well already. I reinvented a few wheels in my time, but doesn't mean I think this one should be. - The reasoning for case 2/3 I already covered upthread. >> 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. > > Codecs needs to be configured also in AG role. Before accepting SCO > connection you need to configure SCO socket for correct codec. Also for > vendor codecs it needs to be properly negotiated via AT commands. > Sure, but that doesn't mean they need an actual D-Bus API to be configured with. You can simply extend oFono emulator to support whatever codecs you want and whatever custom AT command handling that you need. If the HF requests the codec, then you use it. There's no D-Bus API required here. Again, take a look at how this is done in oFono today. >> 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... :) > > So if you are disagreeing with this design, can you propose alternative? > Which would support needs for desktop users? Support for HSP profile (in > AG role), support for HFP profile (in AG role), ability to parse and > interpret needed AT commands. And later also HS and HF role of these > profiles. > There have been one or two implementations of AG role fully external to oFono. These implementations simply used the existing oFono APIs to drive the modem. You could do that. But as I said, we rejected such a design a long time ago due to complexity and other issues. Or you can ignore the call control aspects entirely... But in the end, it is your architecture. All I can do is point out (early in the process) what is and what is not acceptable to oFono upstream. >> >> 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. > > Ok. So I guess now you understood main problem. I thought it was > obvious, but seems that bluetooth HFP is too complicated, so talking > about it always needs more detailed explanation. Sorry for that if it > was not clear from my side since beginning what are requirements for my > setup. Well it was a bit of reading comprehension fail on my part as well. The two roles are really quite different, so precise language helps. Regards, -Denis
WARNING: multiple messages have this Message-ID (diff)
From: Denis Kenzior <denkenz@gmail.com> To: ofono@ofono.org Subject: Re: [pulseaudio-discuss] Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux Date: Thu, 19 Dec 2019 15:01:50 +0000 [thread overview] Message-ID: <90261b42-1048-370f-7680-acd9f7e754ed@gmail.com> (raw) In-Reply-To: <20191219095132.blj3oyyrlfowv5ik@pali> [-- Attachment #1: Type: text/plain, Size: 4747 bytes --] Hi Pali, >>> 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? > > My proposed hsphfpd is going to support both roles. Which means to > implement whole HFP profile. So for connecting bluetooth headsets (when > AG role is needed on desktop) and also for connecting mobile phones > (when HF role is needed on desktop). > > And my primary motivation is for bluetooth headsets as this is what are > asking desktop and laptop users again and again that is missing on Linux > systems. > > So higher priority has AG role and slightly lower priority has HF role. > So to summarize. You have broadly 3 main use cases for HFP: 1. HF connecting to AG role. Essentially a carkit role. oFono does this pretty well already and has the APIs defined that cover up to HFP 1.7. Any vendor extensions can be easily added. And some carkit manufacturers already use it. 2. AG role when you have a 'real modem' behind it. oFono already provides everything needed for this scenario. 3. AG role when you don't have a real modem or you have some sort of VoIP use case. oFono doesn't cover this case as you stated. So I can see value in something that implements case #3. But having said that, oFono will not be receiving AT commands from external daemons: - For case 1, it'd just be a rehash of what oFono does well already. I reinvented a few wheels in my time, but doesn't mean I think this one should be. - The reasoning for case 2/3 I already covered upthread. >> 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. > > Codecs needs to be configured also in AG role. Before accepting SCO > connection you need to configure SCO socket for correct codec. Also for > vendor codecs it needs to be properly negotiated via AT commands. > Sure, but that doesn't mean they need an actual D-Bus API to be configured with. You can simply extend oFono emulator to support whatever codecs you want and whatever custom AT command handling that you need. If the HF requests the codec, then you use it. There's no D-Bus API required here. Again, take a look at how this is done in oFono today. >> 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... :) > > So if you are disagreeing with this design, can you propose alternative? > Which would support needs for desktop users? Support for HSP profile (in > AG role), support for HFP profile (in AG role), ability to parse and > interpret needed AT commands. And later also HS and HF role of these > profiles. > There have been one or two implementations of AG role fully external to oFono. These implementations simply used the existing oFono APIs to drive the modem. You could do that. But as I said, we rejected such a design a long time ago due to complexity and other issues. Or you can ignore the call control aspects entirely... But in the end, it is your architecture. All I can do is point out (early in the process) what is and what is not acceptable to oFono upstream. >> >> 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. > > Ok. So I guess now you understood main problem. I thought it was > obvious, but seems that bluetooth HFP is too complicated, so talking > about it always needs more detailed explanation. Sorry for that if it > was not clear from my side since beginning what are requirements for my > setup. Well it was a bit of reading comprehension fail on my part as well. The two roles are really quite different, so precise language helps. Regards, -Denis
next prev parent reply other threads:[~2019-12-19 14:58 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-01 18:57 Proposal for a new API and usage of Bluetooth HSP and HFP profiles on Linux Pali Rohár 2019-12-02 17:01 ` [pulseaudio-discuss] " Tanu Kaskinen 2019-12-02 17:04 ` Tanu Kaskinen 2019-12-02 18:45 ` Pali Rohár 2019-12-04 15:15 ` Arun Raghavan 2019-12-04 17:05 ` Pali Rohár 2019-12-05 9:32 ` Pali Rohár 2019-12-15 22:11 ` Luiz Augusto von Dentz 2019-12-15 22:14 ` Luiz Augusto von Dentz 2019-12-16 9:15 ` Pali Rohár 2019-12-17 23:47 ` Luiz Augusto von Dentz 2019-12-17 23:50 ` Luiz Augusto von Dentz 2019-12-18 8:30 ` Pali Rohár 2019-12-18 17:00 ` Denis Kenzior 2019-12-18 17:08 ` Denis Kenzior 2019-12-18 17:28 ` Pali Rohár 2019-12-18 17:36 ` Pali Rohár 2019-12-18 20:53 ` Denis Kenzior 2019-12-18 21:01 ` Denis Kenzior 2019-12-18 21:33 ` Pali Rohár 2019-12-19 1:03 ` Denis Kenzior 2019-12-19 1:11 ` Denis Kenzior 2019-12-19 9:51 ` Pali Rohár 2019-12-19 14:53 ` Denis Kenzior [this message] 2019-12-19 15:01 ` Denis Kenzior 2019-12-19 15:33 ` Pali Rohár 2019-12-20 21:19 ` Denis Kenzior 2019-12-20 21:22 ` Denis Kenzior 2019-12-20 22:46 ` Pali Rohár 2020-01-04 10:51 ` Pali Rohár 2020-01-07 17:35 ` Denis Kenzior 2020-01-07 17:39 ` Denis Kenzior 2020-01-07 19:01 ` Pali Rohár 2019-12-02 19:49 ` Sebastian Reichel 2019-12-07 20:09 ` Pali Rohár 2019-12-09 9:43 ` George Kiagiadakis 2019-12-09 11:07 ` Pali Rohár 2020-03-15 14:17 ` Pali Rohár
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=90261b42-1048-370f-7680-acd9f7e754ed@gmail.com \ --to=denkenz@gmail.com \ --cc=arun@arunraghavan.net \ --cc=devkit-devel@lists.freedesktop.org \ --cc=georg@chini.tk \ --cc=hadess@hadess.net \ --cc=linux-bluetooth@vger.kernel.org \ --cc=luiz.dentz@gmail.com \ --cc=marcel@holtmann.org \ --cc=ofono@ofono.org \ --cc=pali.rohar@gmail.com \ --cc=pavel@ucw.cz \ --cc=pulseaudio-discuss@lists.freedesktop.org \ --cc=rtreleaven@bunnykick.ca \ --cc=sre@ring0.de \ --cc=tanuk@iki.fi \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.