Re: [alsa-devel] call/normal switch was Re: omap4-droid4: voice call support was
* Dan Williams dcbw@redhat.com [180402 15:51]:
On Sun, 2018-04-01 at 10:30 -0700, Tony Lindgren wrote:
- Tony Lindgren tony@atomide.com [180401 15:38]:
Found it! Here's what I need to do over n_gsm:
ngsm 1 "AT+CFUN=1" ngsm 1 "AT+CFUN?" ngsm 2 "AT+EACC=3,0" # enable mic ngsm 2 "AT+CLVL=4" # set speaker volume ngsm 2 "AT+CMUT=0" # unmute mic
I tried to look through the QMI dumps we have in libqmi from 2013 (latest Qualcomm posted) and couldn't find anything to do with mic control, speaker volume, or anything like that.
If the modem supports the AT service (which I think it does? Not looking at the libqmi dumps right now) then it could potentially tunnel these AT commands through QMI too.
Perhaps Qualcomm added something to the Voice service after 2013, or perhaps there are other services that might control speaker/mic that we don't have public dumps for yet though.
OK thanks for checking. So probably only n_gsm channel 1 is for normal Qualcomm at commands, and then channel 2 and others are commands implemented by Motorola on the mdm6600.
I guess we'd have to add support for reading and writing to /dev/gsmtty2 at least as it looks like these cannot be accessed via /dev/ttyUSB4. Or at least I have not figured out any other way to access them.
Regards,
Tony
* Tony Lindgren tony@atomide.com [180402 15:59]:
- Dan Williams dcbw@redhat.com [180402 15:51]:
On Sun, 2018-04-01 at 10:30 -0700, Tony Lindgren wrote:
- Tony Lindgren tony@atomide.com [180401 15:38]:
Found it! Here's what I need to do over n_gsm:
ngsm 1 "AT+CFUN=1" ngsm 1 "AT+CFUN?" ngsm 2 "AT+EACC=3,0" # enable mic ngsm 2 "AT+CLVL=4" # set speaker volume ngsm 2 "AT+CMUT=0" # unmute mic
I tried to look through the QMI dumps we have in libqmi from 2013 (latest Qualcomm posted) and couldn't find anything to do with mic control, speaker volume, or anything like that.
If the modem supports the AT service (which I think it does? Not looking at the libqmi dumps right now) then it could potentially tunnel these AT commands through QMI too.
Perhaps Qualcomm added something to the Voice service after 2013, or perhaps there are other services that might control speaker/mic that we don't have public dumps for yet though.
OK thanks for checking. So probably only n_gsm channel 1 is for normal Qualcomm at commands, and then channel 2 and others are commands implemented by Motorola on the mdm6600.
I guess we'd have to add support for reading and writing to /dev/gsmtty2 at least as it looks like these cannot be accessed via /dev/ttyUSB4. Or at least I have not figured out any other way to access them.
Hmm or maybe there is some way to select where qmi to tunnels the AT commands to? Some kind of channel type paramenter like n_gsm has?
Anyways, for trying to figure out things for alsamixer, I tested that ngsm 2 "AT+EACC=3,0" is not related to cpcap audio register settings and the mic is enabled during the call with Pavel's patch with alsamixer "Mode" set to either "Call" or "Normal". Also speaker keeps working during the call toggling between "Call" and "Normal". "Voice" in alsamixer does also control the speaker volume during the call. And setting the second "Speaker" from "Voice" to "HiFi" mutes the speaker.
Then alsamixer capture settings for "Mic2" do change the mic gain as expected, and setting "Right" to "Off" mutes the mic. And then setting "Left" to "Mic 2" turns on the mic again.
So my guess is that ngsm 2 "AT+EACC=3,0" and ngsm 2 "AT+CLVL=4" might control some external amp over the mdm6600 gpio pins? With "AT+CLVL" values being 0 7 it sounds like 3 gpios for that?
Regards,
Tony
Hi!
OK thanks for checking. So probably only n_gsm channel 1 is for normal Qualcomm at commands, and then channel 2 and others are commands implemented by Motorola on the mdm6600.
I guess we'd have to add support for reading and writing to /dev/gsmtty2 at least as it looks like these cannot be accessed via /dev/ttyUSB4. Or at least I have not figured out any other way to access them.
Hmm or maybe there is some way to select where qmi to tunnels the AT commands to? Some kind of channel type paramenter like n_gsm has?
Anyways, for trying to figure out things for alsamixer, I tested that ngsm 2 "AT+EACC=3,0" is not related to cpcap audio register settings and the mic is enabled during the call with Pavel's patch with alsamixer "Mode" set to either "Call" or "Normal". Also speaker keeps working during the call toggling between "Call" and "Normal". "Voice" in alsamixer does also control the speaker volume during the call. And setting the second "Speaker" from "Voice" to "HiFi" mutes the speaker.
Take a look at the patch. Selecting "call" does something at hardware level, selecting "normal" is a nop.
Sorry for confusion.
Yes, that patch needs more work.
Pavel
* Pavel Machek pavel@ucw.cz [180403 15:51]:
Hi!
OK thanks for checking. So probably only n_gsm channel 1 is for normal Qualcomm at commands, and then channel 2 and others are commands implemented by Motorola on the mdm6600.
I guess we'd have to add support for reading and writing to /dev/gsmtty2 at least as it looks like these cannot be accessed via /dev/ttyUSB4. Or at least I have not figured out any other way to access them.
Hmm or maybe there is some way to select where qmi to tunnels the AT commands to? Some kind of channel type paramenter like n_gsm has?
Anyways, for trying to figure out things for alsamixer, I tested that ngsm 2 "AT+EACC=3,0" is not related to cpcap audio register settings and the mic is enabled during the call with Pavel's patch with alsamixer "Mode" set to either "Call" or "Normal". Also speaker keeps working during the call toggling between "Call" and "Normal". "Voice" in alsamixer does also control the speaker volume during the call. And setting the second "Speaker" from "Voice" to "HiFi" mutes the speaker.
Take a look at the patch. Selecting "call" does something at hardware level, selecting "normal" is a nop.
Sorry for confusion.
Yes, that patch needs more work.
OK that explains why the speaker keeps working then :)
Regards,
Tony
Hi!
OK that explains why the speaker keeps working then :)
Ok, I pushed new version of unicsy_demo.
It now sends & receives sms and you can call & receive call. Tone from linphone is used for incoming call. User interface and code is slightly weird, as ofono was -- and still is -- meant as a backend.
Pavel
Hi,
On 06/04/18 14:04, Pavel Machek wrote:
Hi!
OK that explains why the speaker keeps working then :)
Ok, I pushed new version of unicsy_demo.
It now sends & receives sms and you can call & receive call. Tone from linphone is used for incoming call. User interface and code is slightly weird, as ofono was -- and still is -- meant as a backend.
Great news, can't wait to try it.
Did you modify ofono beyond the patches you have already posted? And what version of ofono was that for?
Cheers, Merlijn
On Fri 2018-04-06 14:23:46, Merlijn Wajer wrote:
Hi,
On 06/04/18 14:04, Pavel Machek wrote:
Hi!
OK that explains why the speaker keeps working then :)
Ok, I pushed new version of unicsy_demo.
It now sends & receives sms and you can call & receive call. Tone from linphone is used for incoming call. User interface and code is slightly weird, as ofono was -- and still is -- meant as a backend.
Great news, can't wait to try it.
Did you modify ofono beyond the patches you have already posted? And what version of ofono was that for?
Forget ofono for now. I modified ofone to issue at commands directly. It is .. a hack, but should be good enough for testing.
Best regards, Pavel
On Fri 2018-04-06 14:23:46, Merlijn Wajer wrote:
Hi,
On 06/04/18 14:04, Pavel Machek wrote:
Hi!
OK that explains why the speaker keeps working then :)
Ok, I pushed new version of unicsy_demo.
It now sends & receives sms and you can call & receive call. Tone from linphone is used for incoming call. User interface and code is slightly weird, as ofono was -- and still is -- meant as a backend.
Great news, can't wait to try it.
Oh btw ... if you need any help just ask. unicsy_demo needs to be symlinked to /usr/share/unicsy.
If you could make notes of any problems you encounter and any packages you'll need to install, that would be nice -- it would be good to create README with installation instructions.
Good luck, Pavel
Hi!
It seems qmicli can be used while unicsy_demo/ofone talks to the modem using the AT commands.
So I could do:
qmicli -d /dev/cdc-wdm0 --wds-follow-network --wds-start-network=apn=internet.t-mobile.cz route del default sudo ifconfig wwan0 up dhclient wwan0
to get GPRS/UMTS connection. AT commands still work.
Does anyone have any idea what to do to get the GPS to work?
Pavel
On Sat 2018-04-07 10:10:00, Pavel Machek wrote:
Hi!
It seems qmicli can be used while unicsy_demo/ofone talks to the modem using the AT commands.
So I could do:
qmicli -d /dev/cdc-wdm0 --wds-follow-network --wds-start-network=apn=internet.t-mobile.cz route del default sudo ifconfig wwan0 up dhclient wwan0
to get GPRS/UMTS connection. AT commands still work.
Does anyone have any idea what to do to get the GPS to work?
Got that to work.
I installed modemmanager -- unfortunately that claims ttyUSB4 so it breaks voice/sms -- but then
mmcli -m 0 --enable mmcli -m 0 --location-enable-gps-nmea watch -n .3 sudo mmcli -m 0 --location-get-gps-nmea
...can be used to get GPS data. Droid4 seems to have rather bad GPS, so you should probably put it near window for testing.
Is there way to grab data from modemmanager and feed it to gpsd, so that normal applications can access gps? I don't see easy way.
I tried --location-enable-gps-unmanaged , but that did not work for me.
Is modemmanager enabling GPS, or is it talking to libqmi to do that? The code is quite confusing to me...
Best regards, Pavel
On Sat, 2018-04-07 at 14:22 +0200, Pavel Machek wrote:
On Sat 2018-04-07 10:10:00, Pavel Machek wrote:
Hi!
It seems qmicli can be used while unicsy_demo/ofone talks to the modem using the AT commands.
So I could do:
qmicli -d /dev/cdc-wdm0 --wds-follow-network --wds-start- network=apn=internet.t-mobile.cz route del default sudo ifconfig wwan0 up dhclient wwan0
to get GPRS/UMTS connection. AT commands still work.
Does anyone have any idea what to do to get the GPS to work?
Got that to work.
I installed modemmanager -- unfortunately that claims ttyUSB4 so it breaks voice/sms -- but then
It shouldn't break SMS since MM will do SMS via QMI, but yeah for now it'll break voice because that would happen via QMI too, and we haven't implemented voice for QMI yet.
--help-messaging --help-sms
Also available via D-Bus of course.
mmcli -m 0 --enable mmcli -m 0 --location-enable-gps-nmea watch -n .3 sudo mmcli -m 0 --location-get-gps-nmea
...can be used to get GPS data. Droid4 seems to have rather bad GPS, so you should probably put it near window for testing.
Is there way to grab data from modemmanager and feed it to gpsd, so that normal applications can access gps? I don't see easy way.
I tried --location-enable-gps-unmanaged , but that did not work for me.
That requires a TTY that would spit out the GPS data; in this mode MM only sends the start/stop commands, and what comes out the GPS TTY is undefined (at least by MM).
So unless you know that one of the 6600's TTYs does GPS and in what format it does GPS, then no.
Doesn't --location-get-gps-nmea work for you? That will spit out the latest NMEA traces MM gets from the modem, if it supports NMEA. I believe --location-status will tell you what methods MM supports with the modem.
Also available via D-Bus of course.
Is modemmanager enabling GPS, or is it talking to libqmi to do that? The code is quite confusing to me...
Yes. When the modem is driven with QMI, then all the data comes from QMI. For other modems (like Huawei HiLink and Gobi 1000) the enabling commands are done via AT on the main command port and then one of the TTYs starts spewing out NMEA.
Dan
Hi!
mmcli -m 0 --enable mmcli -m 0 --location-enable-gps-nmea watch -n .3 sudo mmcli -m 0 --location-get-gps-nmea
...can be used to get GPS data. Droid4 seems to have rather bad GPS, so you should probably put it near window for testing.
Is there way to grab data from modemmanager and feed it to gpsd, so that normal applications can access gps? I don't see easy way.
I tried --location-enable-gps-unmanaged , but that did not work for me.
That requires a TTY that would spit out the GPS data; in this mode MM only sends the start/stop commands, and what comes out the GPS TTY is undefined (at least by MM).
So unless you know that one of the 6600's TTYs does GPS and in what format it does GPS, then no.
Doesn't --location-get-gps-nmea work for you? That will spit out the latest NMEA traces MM gets from the modem, if it supports NMEA. I believe --location-status will tell you what methods MM supports with the modem.
Yes, --location-get-gps-nmea works for me.
I guess one way forward would be to implement --location-get-gps-nmea support for qmicli, and use that?
Best regards, Pavel
On Sun, 2018-04-08 at 09:41 +0200, Pavel Machek wrote:
Hi!
mmcli -m 0 --enable mmcli -m 0 --location-enable-gps-nmea watch -n .3 sudo mmcli -m 0 --location-get-gps-nmea
...can be used to get GPS data. Droid4 seems to have rather bad GPS, so you should probably put it near window for testing.
Is there way to grab data from modemmanager and feed it to gpsd, so that normal applications can access gps? I don't see easy way.
I tried --location-enable-gps-unmanaged , but that did not work for me.
That requires a TTY that would spit out the GPS data; in this mode MM only sends the start/stop commands, and what comes out the GPS TTY is undefined (at least by MM).
So unless you know that one of the 6600's TTYs does GPS and in what format it does GPS, then no.
Doesn't --location-get-gps-nmea work for you? That will spit out the latest NMEA traces MM gets from the modem, if it supports NMEA. I believe --location-status will tell you what methods MM supports with the modem.
Yes, --location-get-gps-nmea works for me.
I guess one way forward would be to implement --location-get-gps-nmea support for qmicli, and use that?
Yeah, libqmi already has the necessary bits but it's not plumbed through to qmicli. Note that qmicli is a straight interface to QMI and doesn't try to impose abstractions on anything, so you wouldn't get -- location-get-gps-nmea, but you'd instead be working directly with the QMI PDS (older) and/or LOC (newer) service commands.
Dan
* Dan Williams dcbw@redhat.com [180408 02:46]:
On Sat, 2018-04-07 at 14:22 +0200, Pavel Machek wrote:
I tried --location-enable-gps-unmanaged , but that did not work for me.
That requires a TTY that would spit out the GPS data; in this mode MM only sends the start/stop commands, and what comes out the GPS TTY is undefined (at least by MM).
So unless you know that one of the 6600's TTYs does GPS and in what format it does GPS, then no.
There should be a NMEA port within the unknown port range ttyUSB[123].
Is there some easy way to enable --location-enable-gps-unmanaged for testing so I can check if GPS gets enabled for one of the ports?
Regards,
Tony
On Mon, 2018-04-09 at 07:08 -0700, Tony Lindgren wrote:
- Dan Williams dcbw@redhat.com [180408 02:46]:
On Sat, 2018-04-07 at 14:22 +0200, Pavel Machek wrote:
I tried --location-enable-gps-unmanaged , but that did not work for me.
That requires a TTY that would spit out the GPS data; in this mode MM only sends the start/stop commands, and what comes out the GPS TTY is undefined (at least by MM).
So unless you know that one of the 6600's TTYs does GPS and in what format it does GPS, then no.
There should be a NMEA port within the unknown port range ttyUSB[123].
Is there some easy way to enable --location-enable-gps-unmanaged for testing so I can check if GPS gets enabled for one of the ports?
Not all modems support all of the ModemManager location options; -unmanaged is only for devices that support sending the data to a separate port and for which we know the commands to do that.
It looks like QMI has a way to direct the output to a specific device:
// Enum to describe QMI PDS Output Devices enum eQMIPDSOutputDevices:UINT8 { eQMIPDSOutputDevices_NoneDisabled = 0, eQMIPDSOutputDevices_USB = 1, eQMIPDSOutputDevices_UART1 = 2, eQMIPDSOutputDevices_UART2 = 3, eQMIPDSOutputDevices_SharedMemory = 4, };
so we could add support for that to libqmi and then to ModemManager, which could help implement --location-enable-gps-unmanaged on alternate ports.
But what might be simpler is implementing something like the "QMI GPS proxy" that already exists, but for ModemManager or libqmi directly. That way you can use QMI and get known formatting of the output data, but proxy it to a normal-looking NMEA tty? Instead of trying to figure out which TTY/UART/etc the information comes out of for each specific device and somehow encoding that into the platform. We know what the QMI ports are already, that's easy. We don't know what all the TTYs are for every given modem and hardcoding that info somewhere is error- prone and hard to keep up with.
Dan
On Mon 2018-04-09 07:08:47, Tony Lindgren wrote:
- Dan Williams dcbw@redhat.com [180408 02:46]:
On Sat, 2018-04-07 at 14:22 +0200, Pavel Machek wrote:
I tried --location-enable-gps-unmanaged , but that did not work for me.
That requires a TTY that would spit out the GPS data; in this mode MM only sends the start/stop commands, and what comes out the GPS TTY is undefined (at least by MM).
So unless you know that one of the 6600's TTYs does GPS and in what format it does GPS, then no.
There should be a NMEA port within the unknown port range ttyUSB[123].
Is there some easy way to enable --location-enable-gps-unmanaged for testing so I can check if GPS gets enabled for one of the ports?
In the meantime, I got GPS to work :-).
I modified qmicli to pipe NMEA data to stdout, which should be enough.
But yes, directly exposing NMEA data on ttyGSM? would be even nicer.
Thanks,
Pavel
On Mon 2018-04-09 07:08:47, Tony Lindgren wrote:
- Dan Williams dcbw@redhat.com [180408 02:46]:
On Sat, 2018-04-07 at 14:22 +0200, Pavel Machek wrote:
I tried --location-enable-gps-unmanaged , but that did not work for me.
That requires a TTY that would spit out the GPS data; in this mode MM only sends the start/stop commands, and what comes out the GPS TTY is undefined (at least by MM).
So unless you know that one of the 6600's TTYs does GPS and in what format it does GPS, then no.
There should be a NMEA port within the unknown port range ttyUSB[123].
Is there some easy way to enable --location-enable-gps-unmanaged for testing so I can check if GPS gets enabled for one of the ports?
This should be userful for testing:
Just pass --pds-start-gps and you should get NMEA on stdout.
Cleanup does _not_ work properly, so it will fail if you run it too many times.
Pavel
diff --git a/src/qmicli/Makefile.am b/src/qmicli/Makefile.am index eb63fa7..2c5e935 100644 --- a/src/qmicli/Makefile.am +++ b/src/qmicli/Makefile.am @@ -42,6 +42,7 @@ qmicli_SOURCES = \ qmicli-pdc.c \ qmicli-uim.c \ qmicli-wms.c \ + qmicli-pds.c \ qmicli-wda.c \ qmicli-voice.c \ qmicli-charsets.c \ diff --git a/src/qmicli/qmicli-loc.c b/src/qmicli/qmicli-loc.c new file mode 100644 index 0000000..e69de29 diff --git a/src/qmicli/qmicli-pds.c b/src/qmicli/qmicli-pds.c new file mode 100644 index 0000000..f21ba2e --- /dev/null +++ b/src/qmicli/qmicli-pds.c @@ -0,0 +1,315 @@ +/* -*- Mode: C; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */ +/* + * qmicli -- Command line interface to control QMI devices + * + * This program is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program. If not, see http://www.gnu.org/licenses/. + * + * Copyright (C) 2015-2017 Aleksander Morgado aleksander@aleksander.es + */ + +#include "config.h" + +#include <stdio.h> +#include <stdlib.h> +#include <locale.h> +#include <string.h> + +#include <glib.h> +#include <gio/gio.h> + +#include <libqmi-glib.h> + +#include "qmicli.h" +#include "qmicli-helpers.h" + +/* Context */ +typedef struct { + QmiDevice *device; + QmiClientPds *client; + GCancellable *cancellable; +} Context; +static Context *ctx; + +/* Options */ +static gboolean get_supported_messages_flag; +static gboolean reset_flag; +static gboolean noop_flag; +static gboolean start_flag; + +static GOptionEntry entries[] = { + { "pds-start-gps", 0, 0, G_OPTION_ARG_NONE, &start_flag, + "Start gps", + NULL + }, + + { NULL } +}; + +GOptionGroup * +qmicli_pds_get_option_group (void) +{ + GOptionGroup *group; + + group = g_option_group_new ("pds", + "PDS options", + "Show Wireless Messaging Service options", + NULL, + NULL); + g_option_group_add_entries (group, entries); + + return group; +} + +gboolean +qmicli_pds_options_enabled (void) +{ + static guint n_actions = 0; + static gboolean checked = FALSE; + + if (checked) + return !!n_actions; + + n_actions = (get_supported_messages_flag + + reset_flag + + noop_flag + + start_flag); + + if (n_actions > 1) { + g_printerr ("error: too many PDS actions requested\n"); + exit (EXIT_FAILURE); + } + + checked = TRUE; + return !!n_actions; +} + +#if 0 +static void +context_free (Context *context) +{ + if (!context) + return; + + if (context->client) + g_object_unref (context->client); + g_object_unref (context->cancellable); + g_object_unref (context->device); + g_slice_free (Context, context); +} + +static void +operation_shutdown (gboolean operation_status) +{ + /* Cleanup context and finish async operation */ + context_free (ctx); + qmicli_async_operation_done (operation_status, FALSE); +} +#endif + +static void +ser_location_ready (QmiClientPds *client, + GAsyncResult *res, + GTask *task); + +static void +location_event_report_indication_cb (QmiClientPds *client, + QmiIndicationPdsEventReportOutput *output, + void *self) +{ + QmiPdsPositionSessionStatus session_status; + const gchar *nmea; + + if (qmi_indication_pds_event_report_output_get_position_session_status ( + output, + &session_status, + NULL)) { + printf ("[GPS] session status changed: '%s'", + qmi_pds_position_session_status_get_string (session_status)); + } + + if (qmi_indication_pds_event_report_output_get_nmea_position ( + output, + &nmea, + NULL)) { + printf ("%s", nmea); + } +} + +static void +gather_nmea(GTask *task) +{ + QmiMessagePdsSetEventReportInput *input; + + /* Only gather standard NMEA traces */ + input = qmi_message_pds_set_event_report_input_new (); + qmi_message_pds_set_event_report_input_set_nmea_position_reporting (input, TRUE, NULL); + qmi_client_pds_set_event_report ( + ctx->client, + input, + 5, + NULL, + (GAsyncReadyCallback)ser_location_ready, + task); + qmi_message_pds_set_event_report_input_unref (input); + +} + +static void +ser_location_ready (QmiClientPds *client, + GAsyncResult *res, + GTask *task) +{ + QmiMessagePdsSetEventReportOutput *output = NULL; + GError *error = NULL; + + output = qmi_client_pds_set_event_report_finish (client, res, &error); + if (!output) { + g_prefix_error (&error, "QMI operation failed: "); + g_task_return_error (task, error); + g_object_unref (task); + return; + } + + if (!qmi_message_pds_set_event_report_output_get_result (output, &error)) { + g_prefix_error (&error, "Couldn't set event report: "); + g_task_return_error (task, error); + g_object_unref (task); + qmi_message_pds_set_event_report_output_unref (output); + return; + } + + qmi_message_pds_set_event_report_output_unref (output); + + g_signal_connect (client, + "event-report", + G_CALLBACK (location_event_report_indication_cb), + NULL); +} + +static void +auto_tracking_state_start_ready (QmiClientPds *client, + GAsyncResult *res, + GTask *task) +{ + QmiMessagePdsSetAutoTrackingStateOutput *output = NULL; + GError *error = NULL; + + output = qmi_client_pds_set_auto_tracking_state_finish (client, res, &error); + if (!output) { + g_prefix_error (&error, "QMI operation failed: "); + g_task_return_error (task, error); + g_object_unref (task); + return; + } + + if (!qmi_message_pds_set_auto_tracking_state_output_get_result (output, &error)) { + if (!g_error_matches (error, + QMI_PROTOCOL_ERROR, + QMI_PROTOCOL_ERROR_NO_EFFECT)) { + g_prefix_error (&error, "Couldn't set auto-tracking state: "); + g_task_return_error (task, error); + g_object_unref (task); + qmi_message_pds_set_auto_tracking_state_output_unref (output); + return; + } + g_error_free (error); + printf("no matches: was already enabled?\n"); + } + qmi_message_pds_set_auto_tracking_state_output_unref (output); + gather_nmea(task); +} + + +static void +gps_service_state_start_ready (QmiClientPds *client, + GAsyncResult *res, + GTask *task) +{ + QmiMessagePdsSetAutoTrackingStateInput *input; + QmiMessagePdsSetGpsServiceStateOutput *output = NULL; + GError *error = NULL; + + output = qmi_client_pds_set_gps_service_state_finish (client, res, &error); + if (!output) { + g_prefix_error (&error, "QMI operation failed: "); + g_task_return_error (task, error); + g_object_unref (task); + return; + } + + if (!qmi_message_pds_set_gps_service_state_output_get_result (output, &error)) { + if (!g_error_matches (error, + QMI_PROTOCOL_ERROR, + QMI_PROTOCOL_ERROR_NO_EFFECT)) { + g_prefix_error (&error, "Couldn't set GPS service state: "); + g_task_return_error (task, error); + g_object_unref (task); + qmi_message_pds_set_gps_service_state_output_unref (output); + return; + } + g_error_free (error); + } + qmi_message_pds_set_gps_service_state_output_unref (output); + + /* Enable auto-tracking for a continuous fix */ + input = qmi_message_pds_set_auto_tracking_state_input_new (); + qmi_message_pds_set_auto_tracking_state_input_set_state (input, TRUE, NULL); + qmi_client_pds_set_auto_tracking_state ( + ctx->client, + input, + 10, + NULL, /* cancellable */ + (GAsyncReadyCallback)auto_tracking_state_start_ready, + task); + qmi_message_pds_set_auto_tracking_state_input_unref (input); +} + + +void +qmicli_pds_run (QmiDevice *device, + QmiClientPds *client, + GCancellable *cancellable) +{ + /* Initialize context */ + ctx = g_slice_new (Context); + ctx->device = g_object_ref (device); + ctx->client = g_object_ref (client); + ctx->cancellable = g_object_ref (cancellable); + + if (start_flag) { + QmiMessagePdsSetGpsServiceStateInput *input; + + input = qmi_message_pds_set_gps_service_state_input_new (); + qmi_message_pds_set_gps_service_state_input_set_state (input, TRUE, NULL); + qmi_client_pds_set_gps_service_state ( + ctx->client, + input, + 10, + NULL, /* cancellable */ + (GAsyncReadyCallback)gps_service_state_start_ready, + ctx); + qmi_message_pds_set_gps_service_state_input_unref (input); + printf("GPS started?\n"); + return; + } + + if (1) { // run_flag) + g_signal_connect (client, + "event-report", + G_CALLBACK (location_event_report_indication_cb), + NULL); + } + + g_warn_if_reached (); +} diff --git a/src/qmicli/qmicli.c b/src/qmicli/qmicli.c index fecae8d..32d1052 100644 --- a/src/qmicli/qmicli.c +++ b/src/qmicli/qmicli.c @@ -366,6 +366,9 @@ allocate_client_ready (QmiDevice *dev, case QMI_SERVICE_WMS: qmicli_wms_run (dev, QMI_CLIENT_WMS (client), cancellable); return; + case QMI_SERVICE_PDS: + qmicli_pds_run (dev, QMI_CLIENT_PDS (client), cancellable); + return; case QMI_SERVICE_WDA: qmicli_wda_run (dev, QMI_CLIENT_WDA (client), cancellable); return; @@ -719,6 +722,12 @@ parse_actions (void) actions_enabled++; }
+ /* PDS options? */ + if (qmicli_pds_options_enabled ()) { + service = QMI_SERVICE_PDS; + actions_enabled++; + } + /* WDA options? */ if (qmicli_wda_options_enabled ()) { service = QMI_SERVICE_WDA; @@ -769,6 +778,8 @@ int main (int argc, char **argv) g_option_context_add_group (context, qmicli_uim_get_option_group ()); g_option_context_add_group (context, + qmicli_pds_get_option_group ()); + g_option_context_add_group (context, qmicli_wms_get_option_group ()); g_option_context_add_group (context, qmicli_wda_get_option_group ()); diff --git a/src/qmicli/qmicli.h b/src/qmicli/qmicli.h index 7db7905..0986b66 100644 --- a/src/qmicli/qmicli.h +++ b/src/qmicli/qmicli.h @@ -69,6 +69,14 @@ void qmicli_uim_run (QmiDevice *device, QmiClientUim *client, GCancellable *cancellable);
+ +/* PDS group */ +GOptionGroup *qmicli_pds_get_option_group (void); +gboolean qmicli_pds_options_enabled (void); +void qmicli_pds_run (QmiDevice *device, + QmiClientPds *client, + GCancellable *cancellable); + /* WMS group */ GOptionGroup *qmicli_wms_get_option_group (void); gboolean qmicli_wms_options_enabled (void);
* Pavel Machek pavel@ucw.cz [180410 11:00]:
On Mon 2018-04-09 07:08:47, Tony Lindgren wrote:
- Dan Williams dcbw@redhat.com [180408 02:46]:
On Sat, 2018-04-07 at 14:22 +0200, Pavel Machek wrote:
I tried --location-enable-gps-unmanaged , but that did not work for me.
That requires a TTY that would spit out the GPS data; in this mode MM only sends the start/stop commands, and what comes out the GPS TTY is undefined (at least by MM).
So unless you know that one of the 6600's TTYs does GPS and in what format it does GPS, then no.
There should be a NMEA port within the unknown port range ttyUSB[123].
Is there some easy way to enable --location-enable-gps-unmanaged for testing so I can check if GPS gets enabled for one of the ports?
This should be userful for testing:
Just pass --pds-start-gps and you should get NMEA on stdout.
Hmm maybe also try to check if enabling the GPS this way starts printing something out of /dev/ttyUSB[123]?
Regards,
Tony
On Tue 2018-04-10 06:50:29, Tony Lindgren wrote:
- Pavel Machek pavel@ucw.cz [180410 11:00]:
On Mon 2018-04-09 07:08:47, Tony Lindgren wrote:
- Dan Williams dcbw@redhat.com [180408 02:46]:
On Sat, 2018-04-07 at 14:22 +0200, Pavel Machek wrote:
I tried --location-enable-gps-unmanaged , but that did not work for me.
That requires a TTY that would spit out the GPS data; in this mode MM only sends the start/stop commands, and what comes out the GPS TTY is undefined (at least by MM).
So unless you know that one of the 6600's TTYs does GPS and in what format it does GPS, then no.
There should be a NMEA port within the unknown port range ttyUSB[123].
Is there some easy way to enable --location-enable-gps-unmanaged for testing so I can check if GPS gets enabled for one of the ports?
This should be userful for testing:
Just pass --pds-start-gps and you should get NMEA on stdout.
Hmm maybe also try to check if enabling the GPS this way starts printing something out of /dev/ttyUSB[123]?
No, I did not find anything there :-(.
This combination seems to give me working gps:
sudo src/qmicli/qmicli -d /dev/cdc-wdm0 --pds-start-gps | nc -u 127.0.0.1 5000
/usr/sbin/gpsd -ND 4 udp://127.0.0.1:5000
Best regards, Pavel
participants (4)
-
Dan Williams
-
Merlijn Wajer
-
Pavel Machek
-
Tony Lindgren