| Age | Commit message (Collapse) | Author |
|---|
|
The libmm-glib library, as well as the ModemManager headers installed
as part of the D-Bus service API, have always been LGPLv2+ licensed,
because we want users of the service to rely on them in their own
programs, even if they are proprietary.
Some files had an incorrect GPLv2+ header instead of the LGPLv2+ and
that was confusing. All public headers in the MM API have the correct
license text now.
Signed-off-by: Aleksander Morgado <aleksandermj@chromium.org>
|
|
Signed-off-by: Guido Günther <agx@sigxcpu.org>
|
|
According to 3GPP Rel17.2, TS 38104, band NGRAN-67 is supported.
Currently Qualcomm SDX72 chip support this band and MM would show
a '(null)' info in the "Bands" area.
Band info as below:
n67, 738MHz-758MHz, SDL
Signed-off-by: Slark Xiao <slark_xiao@163.com>
|
|
This adds support for the Cell Broadcast interface allowing to
receive, list, read and delete Cell Broadcast messages via the
org.freedesktop.ModemManager1.Modem.CellBroadcast and
org.freedesktop.ModemManager1.Cbm interfaces.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
|
|
|
|
The value was changed in commit 4ab2c80858e207871d0bdc377988 from
0xFFFFFFFF to 0xFFFFFFF7. Revert that ABI break.
|
|
Adds AT^SFDL based Firmware Download as an update method for supported Cinterion modems.
Signed-off-by: Lukas Voegl <lvoegl@tdt.de>
|
|
|
|
|
|
When a modem is not able to register to the network, MBIM and QMI indications
related to registration reports network rejection cause codes if request is
rejected by the network. This information is currently logged in the ModemManager
but not exposed outside of ModemManager.
These are the changes to define interface to expose network reject cause codes
over d-bus to the above layers which could be used by above layers to present
this information in a user friendly way.
|
|
When the modem is in a failed state because of a SIM-related error,
like a missing SIM, or if the modem is SIM-locked, allow the
Location interface to initialize and be enabled anyway.
This allows someone without a SIM to use the GPS, which does not
particularly require a phone subscription. It also allows
someone with a SIM to use the GPS even if the SIM is still
locked.
This patch was reworked, while keeping the original idea, by:
Aleksander Morgado <aleksander@aleksander.es>
Fixes #183
|
|
adding bandwidth information in mm-dbus interface
for the serving cell. In serving cell, the details
on whether the pcell/scell are from MCS or SCG is
also updated.
Co-author: Shilpa Shivakumar
|
|
According to 3GPP Rel16.3, 38104, band NGRAN-53 is supported.
Band info as below:
n53 2483.5 MHz - 2495 MHz, TDD
Signed-off-by: Slark Xiao <slark_xiao@163.com>
|
|
|
|
|
|
|
|
LTE Band 85 is supported by modems based on Qualcomm 9205 chipset.
|
|
Instead of not creating a modem object, create it in failed state with
the "unknown capabilities" failed state reason.
|
|
A modem using an eSIM without profiles should not be allowed to get
enabled, it should be really treated as a modem without a physical
SIM.
|
|
The rights each contributor has are the ones stated by the GPL/LGPL,
not more and not less.
|
|
|
|
This new method allows querying the modem for information about the
current serving cell(s) as well as any other neighboring cell that may
be found.
The information for the cells is given in an array of dictionaries,
where each element of the dictionary is a new dictionary itself.
Each cell type has a different set of properties that may be given in
the dictionary, and some of those properties in each type are also
applicable under certain conditions (e.g. only applicable to the cell
if it's a 'serving' cell instead of 'neighboring').
The API documentation explains in detail what is expected in each
case.
|
|
Sometimes it's useful to know how a given stored profile was created,
so devices can store and report this kind of information.
|
|
The 'allow-roaming' setting should be considered deprecated for 3GPP
devices that support the new 'roaming-allowance' setting, which is
much more detailed (as it allows to differentiate between partner and
non-partner networks) and may also be stored as part of a profile.
|
|
In 5G capable devices, which can support multiple types of access
types (either 3GPP or non-3GPP), the UE may request to use a 3GPP
access type exclusively, prefer a 3GPP access type, or just report no
preference.
When supported, this field may also be part of the settings that can
be stored as part of a profile.
|
|
|
|
A new set of property+method is added to be able to configure the 5G
specific registration settings, initially defining the support for the
MICO mode.
The property name starts with "Nr5g" instead of "5gNr" because of the
limitations imposed by the GObject type system on how properties with
numbers can be named.
|
|
|
|
|
|
|
|
|
|
Mostly based on the Microsoft extensions for MBIM. They'll need to be
mapped to other protocols (e.g. QMI) somehow.
|
|
This property allows the user to know whether the device is attached
or detached from the packet domain service.
|
|
|
|
|
|
This reverts commit 6ffe84a122b9a79a8f0951af5ee5075f16726bdd.
|
|
(cherry picked from commit 2cb38c568ff1fb26b23bad5e8a2851547448c30e)
|
|
Based on the QDU service newly added in libmbim,
T99W175 module (vid: 0x105b) supports MBIM QDU based update.
|
|
This new setting allows the user setting up the connection to specify
the purpose of the connection being brought up.
Until now, we would always assume that connections are exclusively
brought up for connecting to the Internet, also limited by the
inability to connect to multiple different APNs at the same time.
But that may really not be true as there may be additional services
that may be accessed through other APNs, like MMS services or even
private networks for companies that have their own APNs on a given
operator (e.g. not that uncommon with banks and connected cars).
The new APN type setting will not change the way the bearer is
connected, but will allow the connection manager to decide what kind
of networking setup the specific connection needs.
This new setting can be provided by the user itself, or implicitly
read from the device if the device stores this information.
|
|
Both the Simple.Connect() and Modem.CreateBearer() are updated to
allow a new 'multiplex' setting in the properties provided by the user
in both of these methods.
The new setting expects a MMBearerMultiplexSupport enum indicating
what kind of multiplex needs the user has:
* none: if multiplex must not be used.
* requested: if multiplex should be used if available.
* required: if multiplex must be used.
The underlying implementations will take care of accepting or
rejecting the setting depending on the system and modem capabilities.
|
|
At the moment, ignored ports show up as (unknown) in the ports list
in mmcli. This makes it look like something went wrong while probing.
Actually ModemManager already tracks unknown and ignored ports separately
(MM_PORT_TYPE_UNKNOWN vs MM_PORT_TYPE_IGNORED) but the API always exposes
them as MM_MODEM_PORT_TYPE_UNKNOWN.
Add MM_MODEM_PORT_TYPE_IGNORED and use this for ignored ports so they
show up as (ignored) instead in mmcli.
|
|
Reporting the state when the UE attaches to access restricted local
operator services.
|
|
|
|
|
|
|
|
It's not used anywhere.
|
|
|
|
Instead of flagging them as 'ignored' so that they aren't probed, we
can also flag them as 'audio' now, so that the logic knows which port
to report as used for audio in the Call object.
|
|
So that we can avoid gtk-doc complaining about them:
2019-10-14 10:46:59,583:common.py:ParseEnumDeclaration:427:WARNING:Cannot parse enumeration member:
../../../include/ModemManager-enums.h:924: warning: Value description for MMModemLocationSource::MM_MODEM_LOCATION_SOURCE_FIRST is missing in source code comment block.
../../../include/ModemManager-enums.h:924: warning: Value description for MMModemLocationSource::MM_MODEM_LOCATION_SOURCE_LAST is missing in source code comment block.
|
|
This method allows deflecting an incoming or waiting call to a
different number.
|
