| Age | Commit message (Collapse) | Author |
|---|
|
|
|
It is no longer true that all QMI ports are exposed by the qmi_wwan
driver and that all MBIM ports are exposed by the cdc_mbim driver.
There are other generic setups that allow exposing these types of
ports using different drivers, and usually we can also know the type
of port in advance via other means. Therefore, allow adding udev port
type hints for QMI and MBIM ports as well.
|
|
The .actions file is generated by newer gtk-doc releases, we just
treat it as e.g. the .signals or .types files.
This is also already fixed in upstream gtk-doc:
https://gitlab.gnome.org/GNOME/gtk-doc/-/merge_requests/61
|
|
This is not just a rename of the rule, we also now avoid doing an
explicit check on the port name as well, and we rely on subsystem
checks only; i.e. the same logic applied for net ports.
The port candidate rules already do a 'cdc-wdm*' device name check
so it shouldn't be a big deal.
|
|
It's a private method, so add it in the Private subsection.
|
|
This exposes the new EID property of the SIM object on mmcli.
|
|
This provides a new D-Bus property on the Sim object that
exposes the EID of the SIM, if available.
|
|
|
|
This new method allows changing the SIM slot considered as primary,
when the modem supports multiple SIM slots.
The generic handling of this method will make sure that the modem
object and all its SIM objects are re-probed from scratch as soon as a
successful SIM slot switch happens.
Implementations may report MM_CORE_ERROR_EXISTS when the switch
doesn't need to happen (e.g. if the requested SIM slot is already the
active one).
|
|
The 'SimSlots' property exposes an array of SIM object paths, with one
array item for each available SIM slot in the system. If a valid SIM
card is found in a given slot, the path of the SIM object will be
exposed in the array item; if no valid SIM card is found, the empty
object path ("/") will be exposed instead.
The 'PrimarySimSlot' property exposes which of the SIM slots available
in the system is the one configured as being primary. In a Multi-SIM
Single-Standby setup, the primary slot will be the one corresponding
to the single active SIM in the system. In a Multi-SIM Multi-Standby
setup, the primary slot will be the one configured to act as primary
(e.g. the one that will be used for the data connection) among all the
active SIM cards found.
|
|
In preparation for the multi-SIM setup, we need a way to tell whether
a given SIM card is active or not in the system.
On systems with one single SIM slot, the available SIM card will
always be active.
On Multi-SIM Single-Standby setups we may have multiple SIM slots with
multiple SIM cards, but only one of them will be active at any given
time.
On Multi-SIM Multi-Standby setups we may have multiple SIM slots with
multiple SIM cards that may be active at the same time. E.g. the QMI
protocol allows up to 5 different active SIM cards (primary,
secondary, tertiary...).
|
|
|
|
Extended the ModemManager Signal interface to include 5G signal
information for RSRP, RSRQ and SINR via libqmi. Also extended mmci
to print 5G signal info.
|
|
|
|
Compiling the amount of bytes transferred and received during all
tracked connection attempts, as well as the total duration of all the
connections.
|
|
When we're reusing over and over the same bearer object, we can
provide statistical information about the number of connection
attempts that have been done and how many of them failed.
|
|
It's not used anywhere.
|
|
|
|
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/120
|
|
So that bindings know how to free the list of structs.
This commit ends up triggering an API break in the bindings generated
via GObject introspection, because the methods to access the items of
a MMModem3gppNetwork are no longer treated as Modem3gpp class methods.
E.g. instead of:
ModemManager.Modem3gpp.network_get_operator_code(network)
We should now do:
network.get_operator_code()
There is no API break in libmm-glib.
|
|
|
|
Use <chapter> so that all per-version indices are included in the docs.
|
|
This method is used by the daemon to modify the GList of MMPco
objects, the client should not need to use this method for anything.
|
|
methods
|
|
|
|
|
|
This new flag allows users of the API to know whether general purpose
voice calls are allowed or otherwise only voice calls to the
registered emergency numbers should be performed.
ModemManager won't really do any distinction between emergency and
non-emergency calls at this point, this flag is just an early
indication for the user of the API that no normal voice call should be
attempted.
|
|
|
|
This tag is completely redundant because users can whitelist the
platform TTY ports to use with the more generic ID_MM_DEVICE_PROCESS
tag, which is part of the explicit whitelist filter rule.
|
|
The udev tag that allows flagging devices that MAY be modems
(e.g. USB<->RS232 adapters) is only applicable to TTY devices, so
explicitly specify that in the tag name as well.
|
|
Until now the ID_MM_DEVICE_IGNORE udev tag was being used in the
internal blacklist of devices shipped by ModemManager when running in
either DEFAULT or PARANOID filter modes. The name of the tag is
extremely misleading because it doesn't really make the full device be
ignored, the tag only applied to TTY ports.
This commit repurposes the tag so that it applies to ANY kind of
port (e.g. TTY, NET, cdc-wdm...) and also to any kind of filter type
(i.e. also applicable in STRICT mode).
The internal blacklist shipped by ModemManager, which should NOT be
used in STRICT mode, uses a new tag name, ID_MM_TTY_BLACKLIST.
The new ID_MM_DEVICE_IGNORE tag is therefore much more usable and its
name is really meaningful. If there are users or third-party projects
adding their own udev rules with the ID_MM_DEVICE_IGNORE tag name,
they should have no problem as the new rule is more restrictive than
the old one.
|
|
|
|
|
|
It will be set to TRUE if this call is part of a multiparty call.
|
|
This method allows deflecting an incoming or waiting call to a
different number.
|
|
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 terminate all ongoing calls.
|
|
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.
|
|
|
|
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
|
|
Devices may require/support more than one update method, so instead of
reporting the method as a single enum value, use a set of flags
instead.
|
|
|
|
|
|
|
|
|
|
|
