Re: HSP/HFP ofono bluetooth support for Linux desktop
by Denis Kenzior
Hi Pali,
On 1/8/20 3:25 PM, Pali Rohár wrote:
> Hello!
>
Somehow this went straight to my Junk folder, so I didn't see this
message at all until now.
>
> Audio application (e.g. pulseaudio) really do not want to handle two
> separate services to monitor and process HSP/HFP devices. >
> For audio application are HSP and HFP devices equivalent, they provide
> same features: SCO socket, API for controlling microphone and speaker
> gain; plus optionally specify used codec.
>
> So having two separate services which fully divided for audio
> application purpose does not make sense.
>
> So it is possible that both HSP and HFP audio cards would be available
> via one audio API? Because I do not see how it could be done via design
> like dundee.
>
One API sure. Maybe on multiple services. Honestly, I don't see why
this would be such a burden for PA to watch 2 dbus services instead of
1. From oFono perspective it would make more sense to keep the HSP part
a separate daemon. I could be convinced otherwise if it is indeed a big
burden for PA...
>> You can then implement the same API interfaces for setting up the HSP audio
>> stream as oFono does today (i.e. https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/handsfree...),
>
> This API is unusable for both HSP and HFP audio streams. In pulseaudio
> it is somehow used, but it is not suitable.
>
Funny. "It is used but not suitable"?
> Main objection for handsfree-audio-api.txt is that it does not provide
> information about locally used codec and somehow mixes air codec and
> local codec. In my hsphfpd.txt I used term "AgentCodec" for bluetooth
> local codec and term "AirCodec" for bluetooth air codec format.
Okay. But, just FYI, at the time there was no hw that could do such
on-the-fly conversions, so this use case wasn't considered/implemented.
There's really no reason why we couldn't extend our APIs to handle this.
>
> Another objection against handsfree-audio-api.txt API is that it is
> bound to HF codecs (via number) and does not support for pass e.g. CSR
> codecs.
True. In retrospect we probably should have used strings. But it was
assumed that vendor extensions would go via the Bluetooth SIG Assigned
Numbers facility. Anyhow, we can always add a 'Register2' method that
could take codecs as a string array or a combination of strings & ints.
And if Register2 was used, then use 'NewConnection2' with a signature
that supports passing in vendor codecs and whatever else that might be
needed.
>
> What is completely missing in that API is controlling volume level.
>
It is there on the CallVolume interface
> And also API does not provide socket MTU information or ability to
> change/specify which codec would be used.
There was no need, we automatically defaulted to using Wide band if
available. Third party codecs are a new use case (for oFono HFP), so
would require an API extension.
>
> Non-audio APIs which are needed to export (for both HSP and HFP profiles):
>
> * battery level (0% - 100%)
> * power source (external, battery, unknown)
> * ability to send "our laptop" battery level and power source to remote device
> * send text message to embedded display
> * process button press event (exported via linux kernel uinput)
>
I think all of these are feasible to support under the current oFono
structure, either via plugins or API extensions.
Regards,
-Denis
3 weeks
[PATCH_v4 0/5] Private network request to ConnMan
by Guillaume Zajac
Hi,
Changelog from v3 is:
- Add private-network source/include
- ConnMan plugin is independant from emulator
- Each application that need VPN will pass a callback as argument
when private network is requested. This callback will contain the
private network settings.
Guillaume Zajac (5):
gatppp: Add new contructor to use external fd
private-network: add callback typedef drivers and settings
private-network: add request/release functions and new feature to
Makefile.am
emulator: add request/release private network calls
connman: add plugin in oFono to request request/release private
network
Makefile.am | 10 +-
gatchat/gatppp.c | 33 +++++-
gatchat/gatppp.h | 1 +
gatchat/ppp.h | 2 +-
gatchat/ppp_net.c | 40 ++++---
include/private-network.h | 59 +++++++++
plugins/connman.c | 297 +++++++++++++++++++++++++++++++++++++++++++++
src/emulator.c | 49 ++++++--
src/ofono.h | 6 +
src/private-network.c | 89 ++++++++++++++
10 files changed, 556 insertions(+), 30 deletions(-)
create mode 100644 include/private-network.h
create mode 100644 plugins/connman.c
create mode 100644 src/private-network.c
3 months, 1 week
New phonesim release including Qt5 support?
by Simon Schmeisser
Hi,
I'm a member of the Plasma Mobile team and we are currently trying to
get our messaging and phone stack working. Having a distribution
packaged version of phonesim available would simplify things a lot for
us. However distributions are currently dropping Qt4 support and there
has been no release since Jonah Brüchert introduced support for Qt5 last
year.
So in short, could you please do a new release of phonesim?
Thanks and regards
Simon
9 months, 3 weeks
Using GPS on sim7600
by Louis Rannou
Hello,
I am using a sim7600 with its evaluation kit.
To make the GPS work, I need to send the command AT+CGPS=1. What I can
do is just open the AT port and send the command. But maybe it should be
managed by ofono ? In that case, should I make another plugin, or should
it be included in location reporting ?
By the way, I have no org.ofono.LocationReporting in my dbus interface.
Thanks,
Louis
1 year
ofono enable-modem fails with dbus.exceptions.DBusException:
org.ofono.Error.Failed: Operation failed
by zoltanmaric＠pm.me
I'm trying to make Ubuntu 20.04 recognise AirPods Pro as a headset (not just as headphones). I tried to follow the instructions in this AskUbuntu answer: https://askubuntu.com/questions/831331/failed-to-change-profile-to-headse...
list-modems returns the following output:
[ /phonesim ]
Online = 0
Powered = 0
Lockdown = 0
Emergency = 0
Interfaces =
Features =
Type = hardware
But when I try to run the enable-modem command from a freshly checked-out ofono git repo (commit 285fad8f39d46a5f0a0f9d194789978227558d1e), I get the following error:
Connecting modem /phonesim...
Traceback (most recent call last):
File "./enable-modem", line 20, in <module>
modem.SetProperty("Powered", dbus.Boolean(1), timeout = 120)
File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 72, in __call__
return self._proxy_method(*args, **keywords)
File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 141, in __call__
return self._connection.call_blocking(self._named_service,
File "/usr/lib/python3/dist-packages/dbus/connection.py", line 652, in call_blocking
reply_message = self.send_message_with_reply_and_block(
dbus.exceptions.DBusException: org.ofono.Error.Failed: Operation failed
What does the error mean, and how could I get around it?
Thanks for your help.
1 year
[PATCH v2] quectel: Power on/off with a gpio pulse
by poeschel＠lemonage.de
From: Lars Poeschel <poeschel(a)lemonage.de>
Current implementation uses a gpio level of 1 for powering on quectel
modems using a gpio and a level of 0 for powering off.
This is wrong. Quectel modems use pulses for either power on and power
off. They turn on by the first pulse and turn then off by the next
pulse. The pulse length varies between different modems.
For power on the longest I could in the quectel hardware is "more than
2 seconds" from Quectel M95 Hardware Design Manual.
For Quectel EC21 this is ">= 100 ms".
For Quectel MC60 this is "recommended to be 100 ms".
For Quectel UC15 this is "at least 0.1 s".
For power off the four modems in question vary between a minimum pulse
length of 600-700ms.
This implements a 2100ms pulse for power on and 750ms for power off.
---
plugins/quectel.c | 33 ++++++++++++++++++++++++++++++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/plugins/quectel.c b/plugins/quectel.c
index 6456775d..61ac906e 100644
--- a/plugins/quectel.c
+++ b/plugins/quectel.c
@@ -234,10 +234,21 @@ static void close_ngsm(struct ofono_modem *modem)
ofono_warn("Failed to restore line discipline");
}
+static gboolean gpio_power_off_cb(gpointer user_data)
+{
+ struct ofono_modem *modem = (struct ofono_modem *)user_data;
+ struct quectel_data *data = ofono_modem_get_data(modem);
+ const uint32_t gpio_value = 0;
+
+ l_gpio_writer_set(data->gpio, 1, &gpio_value);
+ ofono_modem_set_powered(modem, FALSE);
+ return false;
+}
+
static void close_serial(struct ofono_modem *modem)
{
struct quectel_data *data = ofono_modem_get_data(modem);
- uint32_t gpio_value = 0;
+ uint32_t gpio_value = 1;
DBG("%p", modem);
@@ -258,8 +269,12 @@ static void close_serial(struct ofono_modem *modem)
else
close_ngsm(modem);
- l_gpio_writer_set(data->gpio, 1, &gpio_value);
- ofono_modem_set_powered(modem, FALSE);
+ if (data->gpio) {
+ l_gpio_writer_set(data->gpio, 1, &gpio_value);
+ g_timeout_add(750, gpio_power_off_cb, modem);
+ } else
+ ofono_modem_set_powered(modem, FALSE);
+
}
static void dbus_hw_reply_properties(struct dbus_hw *hw)
@@ -1096,6 +1111,15 @@ static void init_timeout_cb(struct l_timeout *timeout, void *user_data)
l_timeout_modify_ms(timeout, 500);
}
+static gboolean gpio_power_on_cb(gpointer user_data)
+{
+ struct quectel_data *data = user_data;
+ const uint32_t gpio_value = 0;
+
+ l_gpio_writer_set(data->gpio, 1, &gpio_value);
+ return false;
+}
+
static int open_serial(struct ofono_modem *modem)
{
struct quectel_data *data = ofono_modem_get_data(modem);
@@ -1139,6 +1163,9 @@ static int open_serial(struct ofono_modem *modem)
return -EIO;
}
+ if (data->gpio)
+ g_timeout_add(2100, gpio_power_on_cb, data);
+
/*
* there are three different power-up scenarios:
*
--
2.28.0
1 year
[PATCH] quectel: Possibility to switch power by gpio level
by poeschel＠lemonage.de
From: Lars Poeschel <poeschel(a)lemonage.de>
This does apply on top of my previous patch:
[PATCH v2] quectel: Power on/off with a gpio pulse
-- >8 --
Subject: [PATCH] quectel: Possibility to switch power by gpio level
Normally quectel modems are powered on or off by a gpio pulse on their
PWR_KEY pin.
If you have some special circuitry that powers your modem by gpio level
then this here is for you. You can switch to level behaviour by setting
environment variable OFONO_QUECTEL_GPIO_LEVEL. The gpio goes to high
level for the modem to power on and to low level if it should power off.
---
plugins/quectel.c | 17 ++++++++++++-----
plugins/udevng.c | 5 +++++
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/plugins/quectel.c b/plugins/quectel.c
index 6ab1d6fd..d4a49555 100644
--- a/plugins/quectel.c
+++ b/plugins/quectel.c
@@ -271,10 +271,17 @@ static void close_serial(struct ofono_modem *modem)
close_ngsm(modem);
if (data->gpio) {
- l_gpio_writer_set(data->gpio, 1, &gpio_value);
- g_timeout_add(750, gpio_power_off_cb, modem);
- } else
- ofono_modem_set_powered(modem, FALSE);
+ if (ofono_modem_get_boolean(modem, "GpioLevel")) {
+ gpio_value = 0;
+ l_gpio_writer_set(data->gpio, 1, &gpio_value);
+ } else {
+ l_gpio_writer_set(data->gpio, 1, &gpio_value);
+ g_timeout_add(750, gpio_power_off_cb, modem);
+ return;
+ }
+ }
+
+ ofono_modem_set_powered(modem, FALSE);
}
@@ -1164,7 +1171,7 @@ static int open_serial(struct ofono_modem *modem)
return -EIO;
}
- if (data->gpio)
+ if (data->gpio && !ofono_modem_get_boolean(modem, "GpioLevel"))
g_timeout_add(2100, gpio_power_on_cb, data);
/*
diff --git a/plugins/udevng.c b/plugins/udevng.c
index db13073e..8b1943aa 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -921,6 +921,11 @@ static gboolean setup_quectel_serial(struct modem_info *modem)
if (value)
ofono_modem_set_string(modem->modem, "GpioOffset", value);
+ value = udev_device_get_property_value(info->dev,
+ "OFONO_QUECTEL_GPIO_LEVEL");
+ if (value)
+ ofono_modem_set_boolean(modem->modem, "GpioLevel", TRUE);
+
value = udev_device_get_property_value(info->dev,
"OFONO_QUECTEL_MUX");
if (value)
--
2.28.0
1 year
