| Age | Commit message (Collapse) | Author |
|---|
|
Avoid setting up the Alias rule, which was a helper to let us 'disable' the
systemd service including dbus-activations. Without the Alias, 'disable' will
still let starting ModemManager through dbus-activation. If you really want to
fully disallow starting MM also through dbus-activation, you should 'mask' and
'unmask' the service.
E.g.:
$ sudo systemctl mask ModemManager
ln -s '/dev/null' '/etc/systemd/system/ModemManager.service'
$ sudo mmcli -L
error: couldn't find the ModemManager process in the bus
$ sudo systemctl unmask ModemManager
rm '/etc/systemd/system/ModemManager.service'
$ sudo mmcli -L
No modems were found
https://bugzilla.gnome.org/show_bug.cgi?id=701229
|
|
Based on Dan's tests with QMI modems.
|
|
|
|
Allow having systemd handling the life cycle of the ModemManager process.
|
|
(aleksander) I messed up the integration of commit bc49794848, this should fix
it.
|
|
|
|
It's pointless to have libmm-common around, just merge it into libmm-glib and
make ModemManager depend on libmm-glib directly. At the end, the non-common
stuff in libmm-glib is really minimal.
|
|
|
|
|
|
|
|
We define custom nicks for each error enum, matching the DBus error entry that
we want to have with each of them.
|
|
|
|
|
|
|
|
|
|
Now using the MMSmsPart setup.
|
|
|
|
|
|
|
|
Instead of using type unsafe properties passed to the connect() call, we build
a new object which does the handling of the properties to be passed.
|
|
|
|
|
|
|
|
But keep it around as a static file, while we do the migration to the new
interface.
|
|
|
|
It includes gdbus-codegen generated API documentation, plus the common Enums,
Flags and Errors, which will also be used in libmm-glib.
|
|
This library will not (probably) be installable, but will share the GDBus
and new Enum/Flag/Error type support between the core daemon and the new
libmm-glib library.
|
|
Align autogen.sh with the one in NM:
* Just calling autoreconf once
* Using autopoint from GNU gettext
* Enabling the use of NOCONFIGURE
|
|
The `include/ModemManager-names.h' autogenerated header includes the list of
Interface, Method, Signal and Property names defined in the DBus API.
|
|
Also move helper files to the new `build-aux' directory.
|
|
We expect the responses to start always with <CR><LF>. We just remove anything
that comes before that.
|
|
|
|
|
|
Second in a series. Builds on the previous by actually unit-testing
the sms_parse_pdu() function. Note that the dcf1 test does not pass
as the code is currently written.
|
|
|
|
|
|
Test that a Version Info request/response works as expected, and
add a testcase for a bug where specific Sierra CnS responses to
the Version Info request do not properly return an error when
attempting to parse the response as a QCDM packet. Fix for the
second thing forthcoming.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Bits for CRC calculation and frame escaping/unescaping.
|
|
|
|
|
|
Get rid of dependency on HAL, using libgudev instead. Fix up the plugin API
to no longer use either HAL or udev defines, but let plugins use whatever
mechanism they want for getting more information out of the device given the
subsystem and device node name.
Modems are now defined as "master" devices which "own" a one or more ports.
A port could be a serial tty device or a network device or whatever. The
plugin figures out whether it supports a given port or not and then assigns
it to a new or existing modem. Modems now have a 'valid' property that
should be set to TRUE when the modem has enough ports to operate correctly.
For devices (ex. 'hso') that use a network device for data transfer, the
modem would need to grab at least one TTY and the network device associated
with that physical device to be 'valid'.
Also move the generic modem support code to a plugin like other modem plugins,
and change the I-support-this-device mechanism to return a number indicating
the level of support. For example, the generic plugin would return a quite
low number if the device indicates via probing that it can do GSM or CDMA, but
a more specific plugin can indicate better support for the device, and thus
the more specific plugin would win control.
|
|
|
|
|
