ModemManager will load:
1) The list of supported bands. Note that this doesn't mean that any possible
combination of bands is supported, as modems may support only specific
combinations, but at least gives a rough idea of what the modem is capable
of handling.
2) The list of CURRENT bands. There is no such "Allowed" bands, as we do with
modes, modems will have a specific set of bands being currently used, which
will be reported in the `Bands' property.
If the modem allows modifying the list of bands to use, this can be done with
the `SetBands()' method. If the modem doesn't support using a specific
combination of bands, this method will report an error.
* We will also return 'registration-state' in 3GPP networks
* Specified that 'operator-code' and 'operator-name' are only set if
registered in a 3GPP network.
We don't want to handle bands as flags, in order to avoid the need of 64-bits
for the enum. This change implies that setting allowed bands will be done by
giving an array of uint32 values, signature "au".
This new boolean property, applicable to 3GPP bearers, will specify whether 3GPP
bearers are allowed to get connected when registered in a roaming network.
Elements in a DBus interface name cannot start with a digit, so
"org.freedesktop.ModemManager1.Modem.3gpp" is an invalid interface name.
Renamed here all relevant interfaces so that they have an additional "Modem"
prefix in the element, so we get now:
"org.freedesktop.ModemManager1.Modem.Modem3gpp"
"org.freedesktop.ModemManager1.Modem.Modem3gpp.Ussd"
"org.freedesktop.ModemManager1.Modem.ModemCdma"
Objects generated with gdbus-codegen maintain the previous names.
Keep the Bearer interface out of the 'Modem' subtree in the interface hierarchy,
as it will be specific for Bearer objects, not implemented by Modem objects.
Keep the SMS interface out of the 'Modem' subtree in the interface hierarchy,
as it will be specific for SMS objects, not implemented by Modem objects.
The Scan() method returns an array of dictionaries, where each dictionary is
defined by a string key plus a variant data (not a string data). This is to
handle the "status" and "access-tech" entries, which are given as unsigned
integers.
Supported and Allowed modes are modified to be bitmasks of MM_MODEM_MODE values,
and preference of a specific mode is now given in the new PreferredMode
property and as an extra argument to the SetAllowedModes() call.
* Supported Modes: bitmask specifying which modes are supported by the specific
hardware. For example, a modem may only support 1G/2G/3G connections (not 4G).
* Allowed Modes: bitmask specifying which modes, of the ones Supported by the
modem, are allowed to use. For example, a modem may support 1G/2G/3G connections
but only 1G and 2G connections are allowed by the user as 3G involves more
expensive data rates.
[Allowed] ⊆ [Supported]
* Preferred Mode: specific mode which is preferred among the ones defined in
the Allowed modes bitmask. For example, a modem may allow 1G/2G/3G connections
but the user would like that if possible 2G be used, as 3G consumes too much
battery. If 2G is not possible, 3G can be used.
[Preferred] ∈ [Allowed]
Changing the allowed bands in a modem may fail, for example if trying to set a
frequency band which is not in the bands mask reported as Supported by the modem.
Therefore, we need an explicit SetAllowedBands() method with proper error
reporting instead of making the property writable.
Aleksander Morgado
Nathan Williams