These new methods allow querying and updating the status of the call
waiting network service, as per 3GPP TS 22.083.
The status of the service is not a property because we don't want to
unconditionally load it on every boot, given that the process involves
talking to the network (i.e. it is not a device setting).
This method will join all active and held calls into a single
multiparty call, and then request the network to terminate the call on
the subscriber's end and transfer the control of the call to the
parties that are still in the call.
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.
Modem device inhibition is really a manager action for which we
provide the full modem device 'uid'.
This new operation allows to perform device inhibition using the modem
object as reference, which is more handy than first looking at the
device 'uid' and then running the manager action.
$ sudo mmcli -m 0 --inhibit
successfully inhibited device with uid '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-12/1-12.2'
type Ctrl+C to abort this program and remove the inhibition
^C cancelling the operation...
successfully uninhibited device with uid '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-12/1-12.2'
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
Even if some fields wouldn't apply to some modem, we're always
including all in the output so that clients can assume the fields are
always given.
Fix adding the 3GPP EPS related fields unconditionally.
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.
This patch fixes the following compiler warning:
mmcli-output.c:783:19: error: implicitly declaring library function 'strlen' with type 'unsigned long (const char *)' [-Werror,-Wimplicit-function-declaration]
aux = strlen (section_infos[field_infos[item_l->field].section].name);
^
This patch fixes the following issue with string conversion of a MMCallStateReason enum:
mmcli-call.c:160:88: error: implicit conversion from enumeration type 'MMCallStateReason' to different enumeration type 'MMCallState' [-Werror,-Wenum-conversion]
mmcli_output_string (MMC_F_CALL_PROPERTIES_STATE_REASON, mm_call_state_get_string (mm_call_get_state_reason (call)));
~~~~~~~~~~~~~~~~~~~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In addition to the standard human-friendly output, we now allow a
machine-friendly key-value pair output, much easier to parse and use
by programs that look at the mmcli output.
This new key-value pair output should be treated as API from now on, so
third-party programs can assume the output is compatible from one
release to another.
The --location-get action provides full location information from all
sources, which is better than per-source actions, as those were anyway
using the same API method to load location information as the global
one.
The Simple.GetStatus() method is useful for simple DBus clients that
don't need all the information associated to the modem, just the most
important bits. But, in our case, the information provided by this
method is already given by the standard modem info output, so it is
totally redundant.
This method is completely unnecessary as we have the readable Bearers
property already in place, so let's deprecate it.
Worth noting that the mm_modem_list_bearers() async/sync methods in
libmm-glib were not really using the ListBearers() method anyway, they
are using the property directly. These methods are NOT deprecated,
because they allow us to get a list of MMBearer objects, instead of
just the list of DBus paths that we get when reading the Bearers
property directly.
We also remove --list-bearers from the mmcli operation list as we have
already the same information in the standard modem output.
At this point we want the values enclosed between single quotes,
e.g. so that the fields are parsed easier by scripts.
This issue will not have any practical relevance as soon as the
key-value pair output support is merged.
Remove the redundant declaration of which slipped into the code in commit
091bf4dbd8 ("api: support location assistance data").
Signed-off-by: Ulrich Ölmann <u.oelmann@pengutronix.de>
Aleksander Morgado
Maxim Anisimov
Johny Mattsson
Ben Chan
Dan Williams
Ulrich Ölmann