This method will put the currently active call on hold, and right away
accept the next available call.
The user of the API does not need to specify explicitly which is the
next call to accept, because that is decided automatically:
* If there is any waiting call, it will accept it right away.
* If there is no waiting call but there is a held call, it will make
the held call active again.
This method will hangup the currently active call and right away
accept the next available call.
The user of the API does not need to specify explicitly which is the
next call to accept, because that is decided automatically:
* If there is any waiting call, it will accept it right away.
* If there is no waiting call but there is a held call, it will make
the held call active again.
Which reports the version of the currently active carrier
configuration.
We also update the firmware 'version' reported in the firmware
settings so that carrier-specific upgrades can be performed (e.g. when
the firmware stays the same but the MCFG is updated).
During initialization phase we will allow querying the modem for the
details of which carrier-specific configuration is being used, and
will expose a description string in the API.
In addition to showing the current configuration, we will also allow
automatically switching the configuration based on the SIM card
detected in the device. In order to allow this, plugins/modems will
need to provide the expected mapping between carrier config
description and MCCMNC. This mapping cannot be generic, because
different manufacturers may use different description strings.
No need to process the detailed dictionary if no explicit method is
reported as supported. Avoids unnecessary warnings:
$ mmcli -m 1 --firmware-status
** (mmcli:6887): WARNING **: 15:52:54.664: Invalid initial update settings: Missing required 'device-ids' setting
error: firmware status unsupported
We're running g_async_initable_new_async() ourselves in
mm_manager_new(), so our finish() method should call
g_async_initable_new_finish() explicitly.
There's no change in the logic here, as the generated
mm_gdbus_object_manager_client_new_finish() was already doing this
implicitly.
The MMManager object keeps an internal proxy object for the Manager
interface, and we must make sure we cleanup this object any time the MM
daemon is restarted. Otherwise, the MMManager may end up trying to use
a stale proxy associated to a previous run of the daemon, and e.g. not
showing properly the runtime version info.
E.g., in this sequence with the example python tester, the runtime
version of the daemon was valid only for the first time the daemon
runs, and if the daemon is restarted, mm_manager_get_version()
would keep returning NULL.
$ ./modem-watcher-python
[ModemWatcher] ModemManager service not available in bus
[ModemWatcher] ModemManager 1.9.990 service is available in bus
[ModemWatcher] Dell Inc. (DW5821e Snapdragon X20 LTE) modem managed by ModemManager [None]: /org/freedesktop/ModemManager1/Modem/0
[ModemWatcher] ModemManager service not available in bus
[ModemWatcher] ModemManager None service is available in bus
[ModemWatcher] Dell Inc. (DW5821e Snapdragon X20 LTE) modem managed by ModemManager [None]: /org/freedesktop/ModemManager1/Modem/0
[ModemWatcher] ModemManager service not available in bus
[ModemWatcher] ModemManager None service is available in bus
[ModemWatcher] Dell Inc. (DW5821e Snapdragon X20 LTE) modem managed by ModemManager [None]: /org/freedesktop/ModemManager1/Modem/0
This new method allows users of the ModemManager API to take full
control of a given device.
Unlike other operations in the API, the inhibition is maintained as
long as the caller exists in the bus, or until the same caller
uninhibits the device.
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/98
This property contains the DBus path of a Bearer object of type
MM_BEARER_TYPE_DEFAULT_ATTACH, which is automatically exposed by the
modem when registered in the LTE network.
Unlike standard bearer objects created by the user, this bearer won't
allow any connection/disconnection request, as its status is bound to
the LTE registration exclusively.
The bearer settings exposed by the object include the APN details that
have been used during the initial packet network attach, which may be
defined by modem settings (e.g. if previously configured in the
firmware which APN to use for the given SIM card operator) or by the
network itself (e.g. if none configured, or if a network override is
required as when roaming).
The bearer object will be created as soon as the LTE attach status
details are known, and only while the modem is enabled. The
implementation allows modems to update the LTE attach status details
during runtime, so the bearer object with the settings may be
recreated during runtime as well.
Until now we have only allowed to use and setup 'default bearers' (in
4G) or 'primary contexts' (in 2G/3G).
We can define a couple of additional bearer types, though:
* The 'dedicated bearers' (in 4G) or 'secondary contexts' (in 2G/3G),
which are associated to a specific default/primary one, but which
provide specific QoS settings configured via traffic flow templates.
* The 'initial default EPS bearer', which is a special case of default
bearer in LTE, which is automatically created and connected when the
modem is registered in the LTE network.
This commit introduces a new 'MMBearerType' enumeration that will be
associated to each bearer through a 'BearerType' property in the
org.freedesktop.ModemManager1.Bearer interface, showing what kind of
bearer/context this is.
By default, right now, all bearer objects created are 'default'
bearers.
We were re-using the GDBusObjectManagerClientFlags set in the
MMManager object as GDBusProxyFlags for the Manager1 interface proxy
object, and that was completely broken.
Instead of setting "DO_NOT_AUTO_START" in the proxy, we were actually
setting "DO_NOT_LOAD_PROPERTIES"...
g_assert_cmpmem() isn't available until glib 2.46, while the minimum
glib version required by ModemManager is 2.36. This patch replaces the
uses of g_assert_cmpmem() with memcmp() instead.
The $GNGGA traces provide "combined" values when multiple satellite
constellations are used (e.g. GPS+GLONASS). Prefer these values over
the GPS-only $GPGGA traces if both are received.
E.g. China Mobile (MCC 460, MNC 0).
$ mmcli -m toby --location-get
/org/freedesktop/ModemManager1/Modem/0
-------------------------
3GPP location | Mobile country code: '460'
| Mobile network code: '0'
| Location area code: '6188'
| Cell ID: '40955'
-------------------------
GPS NMEA traces | Not available
-------------------------
Raw GPS | Not available
-------------------------
CDMA BS | Not available
Sometimes SUPL-server based A-GPS is not possible, e.g. if the module
doesn't have Internet connectivity. In such cases, the modem may
support injecting additional "assistance data" that may be downloaded
from the Internet using external means (e.g. WiFi), in order to keep
having a quick time to first fix.
We now support using this location assistance data, with the following
new API elements:
* A new mask of supported assistance data types is provided in the
SupportedAssistanceData property.
* A new list of URLs from where the aassistance data may be
downloaded is also provided in a new AssistanceDataServers
property.
* A new InjectAssistanceData() method is provided, to perform the
data injection in the module once it's been downloaded to the host
system.
Unfortunately, G_MINDOUBLE is basically 0.0, so MM_SIGNAL_UNKNOWN ends
up giving us a value that may fall in the range of expected values for
the signal component.
Update the MM_SIGNAL_UNKNOWN symbol to match a value which is
definitely out any other possible valid range, so that we can easily
detect which values are set and which aren't.
While API is maintained, this fix is introducing an ABI break. Not a
big deal anyway, as the purpose of the value is just to detect unset
fields.
The "location area code" field is given in GSM/UMTS networks
exclusively. LTE networks use the concept of "tracking area code"
instead.
This patch updates the Location interface to Provide separate fields
for LAC and TAC, instead of giving TAC values in the LAC field.
==8663== 1 bytes in 1 blocks are definitely lost in loss record 5 of 4,864
==8663== at 0x4C2CEDF: malloc (vg_replace_malloc.c:299)
==8663== by 0x669FAC9: g_malloc (in /usr/lib/libglib-2.0.so.0.5600.1)
==8663== by 0x66B9AEA: g_strndup (in /usr/lib/libglib-2.0.so.0.5600.1)
==8663== by 0x66ACE52: g_match_info_fetch (in /usr/lib/libglib-2.0.so.0.5600.1)
==8663== by 0x4E96DD2: mm_location_gps_raw_add_trace (mm-location-gps-raw.c:208)
==8663== by 0x18721E: mm_iface_modem_location_gps_update (mm-iface-modem-location.c:264)
==8663== by 0x1B9C7F: loc_location_nmea_indication_cb (mm-shared-qmi.c:712)
==8663== by 0x640C9E7: g_cclosure_marshal_VOID__BOXEDv (in /usr/lib/libgobject-2.0.so.0.5600.1)
==8663== by 0x6409C95: ??? (in /usr/lib/libgobject-2.0.so.0.5600.1)
==8663== by 0x64259E8: g_signal_emit_valist (in /usr/lib/libgobject-2.0.so.0.5600.1)
==8663== by 0x642612F: g_signal_emit (in /usr/lib/libgobject-2.0.so.0.5600.1)
==8663== by 0x54AAB2D: process_indication (qmi-loc.c:7454)
Reported by: Thomas Weißschuh <thomas@weissschuh.net>
Aleksander Morgado
Dan Williams
Ben Chan
Thomas Haller
Guido Günther
Enrico Mioso