| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
This method allows users to modify the settings used during the
initial LTE attach procedure.
|
|
This property shows the settings stored in the device to be used
during the initial LTE attach procedure.
|
|
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 string shows the runtime version of the ModemManager daemon.
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/94
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This prevents errors due to nasty typos in the strings.
We define all symbols in a single header file that is NOT considered
part of the API, as there is no need for MM clients to know about
these tags code-wise. These tags are only meaningful when associated
to devices in udev.
Information of each tag is included in the general API documentation.
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/88
|
|
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.
|
|
This patch adds a 'Pco' property to the Modem3gpp interface for tracking
PCOs that the modem has received from the network.
|
|
|
|
|
|
Section (8) is for tools that require root privileges.
|
|
Reported by: Matthew Stanger <stangerm2@gmail.com>
|
|
|
|
So that we don't forget to add new types here manually...
(e.g. MMBearerStats)
|
|
|
|
The UE modes of operation for LTE are defined in 3GPP TS 24.301 (e.g.
section 4.3 in v10.3.0):
* PS mode 1: EPS only, 'voice centric'
* PS mode 2: EPS only, 'data centric'
* CS/PS mode 1: EPS and non-EPS, 'voice centric'
* CS/PS mode 2: EPS and non-EPS, 'data centric'
The mode specifies, among other things, how the UE should behave w.r.t
CS fallback depending on the capabilities reported by the network.
|
|
|
|
|
|
|
|
This property will let the clients know the hardware revision reported
by the modem.
|
|
When this symbol is defined, e.g. via CFLAGS, building a program that
uses the ModemManager API will fail if the program references
deprecated symbols.
For now we just use it to keep gtk-doc-scan happy and avoid
unnecessary warnings.
|
|
Define new symbols with easier names, just based on the Band Class.
|
|
Flag as deprecated the old names, and define new ones based on the
defined UTRAN band numbers, equivalent to what was done for LTE bands.
|
|
Using an intermediate constant variable breaks compilation with C
compilers, as these variables cannot be used as initializers.
Instead, define a deprecated type and cast all deprecated symbols to
that type. We lose the information about what the new replacement
symbol is, but we don't break compilation.
E.g.:
test.c: In function ‘main’:
test.c:8:5: warning: ‘MMModemBandDeprecated’ is deprecated [-Wdeprecated-declarations]
printf ("band: %d\n", MM_MODEM_BAND_U2100);
^~~~~~
|
|
Commit 6c35878f12ab37604d85cb3a864e3859973bd195 introduced a new option for
setting the refresh rate of location on DBus. This patch describes the option
in the man page.
https://bugs.freedesktop.org/show_bug.cgi?id=89924
|
|
Those Roman numeral suffixes in MM_MODEM_BAND_EUTRAN_* were replaced
with 1, 2, 3, ..., etc. This patch adds a compatibility header,
ModemManager-compat.h, to alias the old MM_MODEM_BAND_EUTRAN_* values to
the new values.
|
|
This logging is available if the software was build with the configure
option --with-systemd-journal.
It will be enabled by default if libsystemd is found.
The runtime parameter --log-journal enables to output of log messages
to the systemd journal.
Please note that the journal priority field has the same value as the
syslog level so no conversion is required here.
|
|
Group together all options that allow configuring the logging output,
and make them have the same --log-[XXX] prefix.
Also rework the --help output so that all option groups are printed by
default (i.e. there is no longer a --help-all option).
|
|
And remove --test-no-auto-scan, as the 'no auto scan' feature isn't
only a test feature now.
|
|
|
|
|
|
This commit enables a new core ModemManager daemon option, so that automatic
detection of available modems is totally disabled: '--no-auto-scan'. Note that
this option also replaces the previously used '--test-no-auto-scan' option,
which was only used during tests.
Along with the new ModemManager option, a new ReportKernelEvent() method in
the API is defined, which allows notifying the daemon of which interfaces it
should be accessing, as well as the main details of each interface. The only
mandatory parameters in the new method are 'action' (add/remove), 'name' (the
name of the interface) and 'subsystem' (the subsystem of the interface).
The mmcli tool has support for using the new api method via several new options:
* The '--report-kernel-event' option allows specifying device ports one by
one, and is a direct mapping of the ReportKernelEvent() method:
$ sudo mmcli --report-kernel-event="action=add,name=wwan0,subsystem=net"
$ sudo mmcli --report-kernel-event="action=add,name=cdc-wdm0,subsystem=usbmisc"
* The '--report-kernel-event-auto-scan' option uses udev monitoring to notify
events automatically to the daemon. This allows to operate in a way
equivalent to the default daemon operation (with implicit auto-scan).
Worth noting that the ReportKernelEvent() method is only usable when
'--no-auto-scan' is explicitly used in the daemon. An error will be reported if
the method is tried while standard udev monitoring is enabled (implicit if
auto scan isn't explicitly disabled in the daemon).
If mmcli is going to be used only to report 'real time' events, an optional
'--initial-kernel-events=[PATH]' may be given in the ModemManager call to
automatically process a set of port kernel events one by one on boot. The file
may e.g. contain:
action=add,name=wwan0,subsystem=net
action=add,name=cdc-wdm0,subsystem=usbmisc
|
|
|
