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
2 weeks, 3 days
[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
[PATCH 1/1] remove obsolete m4 macro
by Nikhil Jha
As per https://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html
LT_INIT should be used instead.
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 3655a112..06ba5290 100644
--- a/configure.ac
+++ b/configure.ac
@@ -28,7 +28,7 @@ m4_define([_LT_AC_TAGCONFIG], [])
m4_ifdef([AC_LIBTOOL_TAGS], [AC_LIBTOOL_TAGS([])])
AC_DISABLE_STATIC
-AC_PROG_LIBTOOL
+LT_INIT
AC_ARG_ENABLE(optimization, AC_HELP_STRING([--disable-optimization],
[disable code optimization through compiler]), [
--
2.26.2
1 year
Unable to establish ppp connection with Huawei dongle
by rakespani＠gmail.com
Hi ,
I am trying to enable lte connection with huawei dongle , but I am getting below error log for activat/context.
Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: Modem: > AT+CGDCONT=1,"IP","airtelgprs.com"\r
Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: Modem: < \r\nOK\r\n
Aug 26 11:36:28 raspberrypi3 daemon.debug ofonod[147]: ../ofono-1.24/drivers/atmodem/gprs-context.c:at_cgdcont_cb() ok 1
Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: Modem: > AT+CGDATA="PPP",1\r
Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: Modem: < \r\nCONNECT 100000000\r\n
Aug 26 11:36:28 raspberrypi3 daemon.debug ofonod[147]: ../ofono-1.24/drivers/atmodem/gprs-context.c:at_cgdata_cb() ok 1
Aug 26 11:36:28 raspberrypi3 daemon.debug ofonod[147]: ../ofono-1.24/drivers/atmodem/gprs-context.c:setup_ppp()
Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 0:INITIAL
Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: PPP: event: 0 (Up), action: 2, new_state: 2 (CLOSED)
Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 2:CLOSED
Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: PPP: event: 2 (Open), action: 1026, new_state: 6 (REQSENT)
Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_initialize_restart_count: current state 2:CLOSED
Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 2:CLOSED
Aug 26 11:36:28 raspberrypi3 daemon.info ofonod[147]: PPP: ../ofono-1.24/gatchat/gatppp.c:ppp_enter_phase() 1
Aug 26 11:36:29 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^BOOT:1113056,0,0,0,99\r\n
Aug 26 11:36:30 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n
Aug 26 11:36:30 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^LTERSRP:-76,-6\r\n
Aug 26 11:36:31 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT
Aug 26 11:36:31 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT
Aug 26 11:36:31 raspberrypi3 daemon.info ofonod[147]: PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT)
Aug 26 11:36:31 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT
Aug 26 11:36:33 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n
Aug 26 11:36:33 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^LTERSRP:-76,-6\r\n
Aug 26 11:36:34 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT
Aug 26 11:36:34 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT
Aug 26 11:36:34 raspberrypi3 daemon.info ofonod[147]: PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT)
Aug 26 11:36:34 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT
Aug 26 11:36:36 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n
Aug 26 11:36:36 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^LTERSRP:-76,-6\r\n
Aug 26 11:36:37 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT
Aug 26 11:36:37 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT
Aug 26 11:36:37 raspberrypi3 daemon.info ofonod[147]: PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT)
Aug 26 11:36:37 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT
Aug 26 11:36:39 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n\r\n^LTERSRP:-76,-6\r\n
Aug 26 11:36:40 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT
Aug 26 11:36:40 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT
Aug 26 11:36:40 raspberrypi3 daemon.info ofonod[147]: PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT)
Aug 26 11:36:40 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT
Aug 26 11:36:42 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n
Aug 26 11:36:42 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^LTERSRP:-76,-6\r\n
Aug 26 11:36:43 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT
Aug 26 11:36:43 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT
Aug 26 11:36:43 raspberrypi3 daemon.info ofonod[147]: PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT)
Aug 26 11:36:43 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT
Aug 26 11:36:45 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n
Aug 26 11:36:45 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^LTERSRP:-76,-6\r\n
Aug 26 11:36:46 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT
Aug 26 11:36:46 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT
Aug 26 11:36:46 raspberrypi3 daemon.info ofonod[147]: PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT)
Aug 26 11:36:46 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT
Aug 26 11:36:48 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n
Aug 26 11:36:48 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^LTERSRP:-76,-6\r\n
Aug 26 11:36:49 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT
Aug 26 11:36:49 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT
Aug 26 11:36:49 raspberrypi3 daemon.info ofonod[147]: PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT)
Aug 26 11:36:49 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT
Aug 26 11:36:51 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n
Aug 26 11:36:51 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^LTERSRP:-76,-6\r\n
Aug 26 11:36:52 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT
Aug 26 11:36:52 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT
Aug 26 11:36:52 raspberrypi3 daemon.info ofonod[147]: PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT)
Aug 26 11:36:52 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT
Aug 26 11:36:54 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n
Aug 26 11:36:54 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^LTERSRP:-76,-9\r\n
Aug 26 11:36:55 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT
Aug 26 11:36:55 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT
Aug 26 11:36:55 raspberrypi3 daemon.info ofonod[147]: PPP: event: 4 (TO+), action: 1006, new_state: 6 (REQSENT)
Aug 26 11:36:55 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_send_configure_request: current state 6:REQSENT
Aug 26 11:36:57 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^RSSI:31\r\n
Aug 26 11:36:57 raspberrypi3 daemon.info ofonod[147]: PCUI: < \r\n^LTERSRP:-76,-7\r\n
Aug 26 11:36:58 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_timeout: current state 6:REQSENT
Aug 26 11:36:58 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT
Aug 26 11:36:58 raspberrypi3 daemon.info ofonod[147]: PPP: event: 5 (TO-), action: 803, new_state: 3 (STOPPED)
Aug 26 11:36:58 raspberrypi3 daemon.info ofonod[147]: PPP: lcp: pppcp_this_layer_finished: current state 3:STOPPED
Aug 26 11:36:58 raspberrypi3 daemon.info ofonod[147]: PPP: ../ofono-1.24/gatchat/gatppp.c:ppp_enter_phase() 0
Aug 26 11:36:58 raspberrypi3 daemon.info ofonod[147]: PPP: ../ofono-1.24/gatchat/gatppp.c:ppp_dead()
Aug 26 11:36:58 raspberrypi3 daemon.debug ofonod[147]: ../ofono-1.24/drivers/atmodem/gprs-context.c:ppp_disconnect() Reason: 0
Aug 26 11:36:58 raspberrypi3 daemon.debug ofonod[147]: ../ofono-1.24/src/gprs.c:pri_activate_callback() 0x165b9a8
Aug 26 11:36:58 raspberrypi3 daemon.debug ofonod[147]: ../ofono-1.24/src/gprs.c:pri_activate_callback() Activating context failed with error: Unknown error type
1 year, 1 month
[PATCH v2] atmodem: Detect usage of AT+CGEREP
by poeschel＠lemonage.de
From: Lars Poeschel <poeschel(a)lemonage.de>
Currently AT+CGEREP=2,1 is sent in case we don't know what the modem
needs. (default case) Not all modems understand this. So, we first query
what the modem supports with AT+CGEREP=? and then use this information
to be nice to the modem. This way modems, like the Quectel M95 that do
only understand AT+CGEREP=1 do also work nicely.
---
drivers/atmodem/gprs.c | 59 ++++++++++++++++++++++++++++++++++++++++--
1 file changed, 57 insertions(+), 2 deletions(-)
diff --git a/drivers/atmodem/gprs.c b/drivers/atmodem/gprs.c
index 68470f11..443bdf77 100644
--- a/drivers/atmodem/gprs.c
+++ b/drivers/atmodem/gprs.c
@@ -45,6 +45,7 @@
#define MAX_CONTEXTS 255
static const char *cgreg_prefix[] = { "+CGREG:", NULL };
+static const char *cgerep_prefix[] = { "+CGEREP:", NULL };
static const char *cgdcont_prefix[] = { "+CGDCONT:", NULL };
static const char *cgact_prefix[] = { "+CGACT:", NULL };
static const char *none_prefix[] = { NULL };
@@ -648,6 +649,60 @@ static void gprs_initialized(gboolean ok, GAtResult *result, gpointer user_data)
ofono_gprs_register(gprs);
}
+static void at_cgerep_test_cb(gboolean ok, GAtResult *result,
+ gpointer user_data)
+{
+ struct ofono_gprs *gprs = user_data;
+ struct gprs_data *gd = ofono_gprs_get_data(gprs);
+ GAtResultIter iter;
+ int min, max, arg1 = 0, arg2 = 0;
+ gboolean two_arguments = true;
+ char buf[20];
+
+ if (!ok)
+ return;
+
+ g_at_result_iter_init(&iter, result);
+
+ g_at_result_iter_next(&iter, "+CGEREP:");
+
+ if (!g_at_result_iter_open_list(&iter))
+ return;
+
+ while (g_at_result_iter_next_range(&iter, &min, &max)) {
+ if ((min <= 1) && (max >= 1))
+ arg1 = 1;
+
+ if ((min <= 2) && (max >= 2))
+ arg1 = 2;
+ }
+
+ if (!g_at_result_iter_close_list(&iter))
+ return;
+
+ if (!g_at_result_iter_open_list(&iter)) {
+ two_arguments = false;
+ goto out;
+ }
+
+ while (g_at_result_iter_next_range(&iter, &min, &max)) {
+ if (min <= 1 <= max)
+ arg2 = 1;
+ }
+
+ if (!g_at_result_iter_close_list(&iter))
+ return;
+
+out:
+ if (two_arguments)
+ sprintf(buf, "AT+CGEREP=%u,%u", arg1, arg2);
+ else
+ sprintf(buf, "AT+CGEREP=%u", arg1);
+
+ g_at_chat_send(gd->chat, buf, none_prefix, gprs_initialized, gprs,
+ NULL);
+}
+
static void at_cgreg_test_cb(gboolean ok, GAtResult *result,
gpointer user_data)
{
@@ -702,8 +757,8 @@ retry:
gprs_initialized, gprs, NULL);
break;
default:
- g_at_chat_send(gd->chat, "AT+CGEREP=2,1", none_prefix,
- gprs_initialized, gprs, NULL);
+ g_at_chat_send(gd->chat, "AT+CGEREP=?", cgerep_prefix,
+ at_cgerep_test_cb, gprs, NULL);
break;
}
--
2.28.0
1 year, 1 month
[PATCH 1/2] atmodem: Detect usage of AT+CGEREP
by poeschel＠lemonage.de
From: Lars Poeschel <poeschel(a)lemonage.de>
Currently AT+CGEREP=2,1 is sent in case we don't know what the modem
needs. (default case) Not all modems understand this. So, we first query
what the modem supports with AT+CGEREP=? and then use this information
to be nice to the modem. This way modems, like the Quectel M95 that do
only understand AT+CGEREP=1 do also work nicely.
---
drivers/atmodem/gprs.c | 75 ++++++++++++++++++++++++++++++++++++++++--
1 file changed, 73 insertions(+), 2 deletions(-)
diff --git a/drivers/atmodem/gprs.c b/drivers/atmodem/gprs.c
index d829e2e6..3900b95b 100644
--- a/drivers/atmodem/gprs.c
+++ b/drivers/atmodem/gprs.c
@@ -45,6 +45,7 @@
#define MAX_CONTEXTS 255
static const char *cgreg_prefix[] = { "+CGREG:", NULL };
+static const char *cgerep_prefix[] = { "+CGEREP:", NULL };
static const char *cgdcont_prefix[] = { "+CGDCONT:", NULL };
static const char *cgact_prefix[] = { "+CGACT:", NULL };
static const char *none_prefix[] = { NULL };
@@ -647,6 +648,76 @@ static void gprs_initialized(gboolean ok, GAtResult *result, gpointer user_data)
ofono_gprs_register(gprs);
}
+static void at_cgerep_test_cb(gboolean ok, GAtResult *result,
+ gpointer user_data)
+{
+ struct ofono_gprs *gprs = user_data;
+ struct gprs_data *gd = ofono_gprs_get_data(gprs);
+ GAtResultIter iter;
+ int min1, max1 = 1, min2, max2 = 1;
+ gboolean two_arguments = true;
+ char buf[20];
+
+ if (!ok)
+ return;
+
+ g_at_result_iter_init(&iter, result);
+
+ g_at_result_iter_next(&iter, "+CGEREP:");
+
+ if (!g_at_result_iter_open_list(&iter))
+ return;
+
+ if (!g_at_result_iter_next_range(&iter, &min1, &max1))
+ return;
+
+ /* if min1 == max1 we had no range but a list and that
+ * means we are interested in the last number of that list*/
+ if (min1 == max1) {
+ while (!g_at_result_iter_close_list(&iter)) {
+ if (!g_at_result_iter_next_number(&iter, &max1))
+ break;
+ }
+ }
+
+ if (!g_at_result_iter_skip_next(&iter)) {
+ two_arguments = false;
+ goto out;
+ }
+
+ if (!g_at_result_iter_open_list(&iter)) {
+ two_arguments = false;
+ goto out;
+ }
+
+ if (!g_at_result_iter_next_range(&iter, &min2, &max2)) {
+ two_arguments = false;
+ goto out;
+ }
+
+ if (min2 == max2) {
+ while (!g_at_result_iter_close_list(&iter)) {
+ if (!g_at_result_iter_next_number(&iter, &max2)) {
+ break;
+ }
+ }
+ }
+
+out:
+ if (max1 > 2)
+ max1 = 2;
+
+ if (max2 > 1)
+ max2 = 1;
+
+ if (two_arguments)
+ sprintf(buf, "AT+CGEREP=%u,%u", max1, max2);
+ else
+ sprintf(buf, "AT+CGEREP=%u", max1);
+
+ g_at_chat_send(gd->chat, buf, none_prefix, gprs_initialized, gprs, NULL);
+}
+
static void at_cgreg_test_cb(gboolean ok, GAtResult *result,
gpointer user_data)
{
@@ -701,8 +772,8 @@ retry:
gprs_initialized, gprs, NULL);
break;
default:
- g_at_chat_send(gd->chat, "AT+CGEREP=2,1", none_prefix,
- gprs_initialized, gprs, NULL);
+ g_at_chat_send(gd->chat, "AT+CGEREP=?", cgerep_prefix,
+ at_cgerep_test_cb, gprs, NULL);
break;
}
--
2.27.0
1 year, 1 month
[PATCH v2] atmodem: Signal quality on quectel serial modems
by poeschel＠lemonage.de
From: Lars Poeschel <poeschel(a)lemonage.de>
As the default way of getting the signal quality with +CIND is also
unstable on quectel serial modems (the same as on quectel EC21). In fact
the signal quality is only updated on cell changes. Those trigger a
manual AT+CSQ in ofono and get an update this way, but the URCs do not
work.
So we implement a quectelish way here as well. The quectelish way is
very similar to the way ifx modems work. We can reuse their csq_notify
function.
---
drivers/atmodem/network-registration.c | 24 +++++++++++++++++++++---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/atmodem/network-registration.c b/drivers/atmodem/network-registration.c
index 78b1994c..c1309f61 100644
--- a/drivers/atmodem/network-registration.c
+++ b/drivers/atmodem/network-registration.c
@@ -780,15 +780,26 @@ static void ifx_xciev_notify(GAtResult *result, gpointer user_data)
*/
}
-static void ifx_xcsq_notify(GAtResult *result, gpointer user_data)
+static void ifx_quec_csq_notify(GAtResult *result, gpointer user_data)
{
struct ofono_netreg *netreg = user_data;
+ struct at_netreg_data *nd = ofono_netreg_get_data(netreg);
int rssi, ber, strength;
GAtResultIter iter;
+ const char *prefix;
g_at_result_iter_init(&iter, result);
- if (!g_at_result_iter_next(&iter, "+XCSQ:"))
+ switch (nd->vendor) {
+ case OFONO_VENDOR_QUECTEL_SERIAL:
+ prefix = "+CSQN:";
+ break;
+ default:
+ prefix = "+XCSQ:";
+ break;
+ }
+
+ if (!g_at_result_iter_next(&iter, prefix))
return;
if (!g_at_result_iter_next_number(&iter, &rssi))
@@ -2027,7 +2038,7 @@ static void at_creg_set_cb(gboolean ok, GAtResult *result, gpointer user_data)
/* Register for specific signal strength reports */
g_at_chat_register(nd->chat, "+XCIEV:", ifx_xciev_notify,
FALSE, netreg, NULL);
- g_at_chat_register(nd->chat, "+XCSQ:", ifx_xcsq_notify,
+ g_at_chat_register(nd->chat, "+XCSQ:", ifx_quec_csq_notify,
FALSE, netreg, NULL);
g_at_chat_send(nd->chat, "AT+XCSQ=1", none_prefix,
NULL, NULL, NULL);
@@ -2118,6 +2129,13 @@ static void at_creg_set_cb(gboolean ok, GAtResult *result, gpointer user_data)
g_at_chat_send(nd->chat, "AT+QINDCFG=\"act\",1", none_prefix,
NULL, NULL, NULL);
break;
+ case OFONO_VENDOR_QUECTEL_SERIAL:
+ g_at_chat_register(nd->chat, "+CSQN:",
+ ifx_quec_csq_notify, FALSE, netreg, NULL);
+ /* Register for specific signal strength reports */
+ g_at_chat_send(nd->chat, "AT+QEXTUNSOL=\"SQ\",1", none_prefix,
+ NULL, NULL, NULL);
+ break;
default:
g_at_chat_send(nd->chat, "AT+CIND=?", cind_prefix,
cind_support_cb, netreg, NULL);
--
2.27.0
1 year, 1 month
[RFC PATCH] atmodem: Signal quality on quectel serial modems
by poeschel＠lemonage.de
From: Lars Poeschel <poeschel(a)lemonage.de>
As the default way of getting the signal quality with +CIND is also
unstable on quectel serial modems (the same as on quectel EC21). In fact
the signal quality is only updated on cell changes. Those trigger a
manual AT+CSQ in ofono and get an update this way, but the URCs do not
work.
So we implement a quectelish way here as well.
--- >8 ---
I send this patch as a RFC because the quectel_csqn_notify function
very much duplicates the ifx_xcsq_notify function despite the "+CSQN"
string. I did not see a good way to reuse the already existing
function because the callback interface only has one user defined
pointer and this is used by the struct ofono_netreg pointer already.
Does anyone have a better idea ?
Thanks,
Lars
---
drivers/atmodem/network-registration.c | 34 ++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/drivers/atmodem/network-registration.c b/drivers/atmodem/network-registration.c
index 78b1994c..74829201 100644
--- a/drivers/atmodem/network-registration.c
+++ b/drivers/atmodem/network-registration.c
@@ -1017,6 +1017,33 @@ static void quectel_qind_notify(GAtResult *result, gpointer user_data)
}
}
+static void quectel_csqn_notify(GAtResult *result, gpointer user_data)
+{
+ struct ofono_netreg *netreg = user_data;
+ int rssi, ber, strength;
+ GAtResultIter iter;
+
+ g_at_result_iter_init(&iter, result);
+
+ if (!g_at_result_iter_next(&iter, "+CSQN:"))
+ return;
+
+ if (!g_at_result_iter_next_number(&iter, &rssi))
+ return;
+
+ if (!g_at_result_iter_next_number(&iter, &ber))
+ return;
+
+ DBG("rssi %d ber %d", rssi, ber);
+
+ if (rssi == 99)
+ strength = -1;
+ else
+ strength = (rssi * 100) / 31;
+
+ ofono_netreg_strength_notify(netreg, strength);
+}
+
static gboolean notify_time(gpointer user_data)
{
struct ofono_netreg *netreg = user_data;
@@ -2118,6 +2145,13 @@ static void at_creg_set_cb(gboolean ok, GAtResult *result, gpointer user_data)
g_at_chat_send(nd->chat, "AT+QINDCFG=\"act\",1", none_prefix,
NULL, NULL, NULL);
break;
+ case OFONO_VENDOR_QUECTEL_SERIAL:
+ g_at_chat_register(nd->chat, "+CSQN:",
+ quectel_csqn_notify, FALSE, netreg, NULL);
+ /* Register for specific signal strength reports */
+ g_at_chat_send(nd->chat, "AT+QEXTUNSOL=\"SQ\",1", none_prefix,
+ NULL, NULL, NULL);
+ break;
default:
g_at_chat_send(nd->chat, "AT+CIND=?", cind_prefix,
cind_support_cb, netreg, NULL);
--
2.27.0
1 year, 2 months
[PATCH v2 0/3] gemalto: USB ethernet data path for ELS81x
by Sergey Matyukevich
Hi Denis and all,
This patch series enables USB ethernet data path for gemalto modems
that support this feature, in particular for ELS81x devices.
Regards,
Sergey
v1 -> v2
- replace g_try_new0 by use g_new0
- drop patch with incorrect fix for modem init
Sergey Matyukevich (3):
drivers: gemalto: add gprs-context driver
plugins: udevng: detect gemalto network interfaces
plugins: gemalto: alternative gprs-context driver
Makefile.am | 3 +-
drivers/gemaltomodem/gemaltomodem.c | 4 +-
drivers/gemaltomodem/gemaltomodem.h | 3 +
drivers/gemaltomodem/gprs-context.c | 278 ++++++++++++++++++++++++++++
plugins/gemalto.c | 12 +-
plugins/udevng.c | 14 +-
6 files changed, 308 insertions(+), 6 deletions(-)
create mode 100644 drivers/gemaltomodem/gprs-context.c
--
2.28.0
1 year, 2 months
