aboutsummaryrefslogtreecommitdiff
path: root/README
diff options
context:
space:
mode:
authorGuido Günther <agx@sigxcpu.org>2014-02-05 08:38:36 +0100
committerGuido Günther <agx@sigxcpu.org>2014-02-05 08:38:36 +0100
commitafc4b839a31c530d73b91aa2483795f185eb7e52 (patch)
tree68655a93926a9981b4d49b66106646efbb2d7c17 /README
parent13ed135b9ae78c692dc359976eb8b54d0a3629b8 (diff)
Imported Upstream version 1.0.0upstream/1.0.0
Diffstat (limited to 'README')
-rw-r--r--README44
1 files changed, 21 insertions, 23 deletions
diff --git a/README b/README
index a95b6db..6ad91ec 100644
--- a/README
+++ b/README
@@ -1,34 +1,32 @@
ModemManager.
-The problem ModemManager tries to solve is to provide a unified high level API
-for communicating with (mobile broadband) modems. While the basic commands are
-standardized, the more advanced operations (like signal quality monitoring
-while connected) varies a lot.
+ModemManager provides a unified high level API for communicating with mobile
+broadband modems, regardless of the protocol used to communicate with the
+actual device (Generic AT, vendor-specific AT, QCDM, QMI, MBIM...).
Using.
ModemManager is a system daemon and is not meant to be used directly from
-the command line. However, since it provides DBus API, it is possible to use
-'dbus-send' command to control it from the terminal. There's an example
-program (tests/mm-test.py) that demonstrates the basic API usage.
+the command line. However, since it provides a DBus API, it is possible to use
+'dbus-send' commands or the new 'mmcli' command line interface to control it
+from the terminal. The devices are queried from udev and automatically updated
+based on hardware events, although a manual re-scan can also be requested to
+look for RS232 modems.
Implementation.
-ModemManager is a DBus system bus activated service (meaning it's started
-automatically when a request arrives). It is written in C. The devices are
-queried from udev and automatically updated based on hardware events. There's
-a GInterface (MMModem) that defines the modem interface and any device specific
-implementation must implement it. There are two generic MMModem implementations
-to support the basic operations (one for GSM, one for CDMA,) which are common
-for all cards.
+ModemManager is a DBus system bus activated service (meaning it's started
+automatically when a request arrives). It is written in C, using glib and gio.
+Several GInterfaces specify different features that the modems support,
+including the generic MMIfaceModem3gpp and MMIfaceModemCdma which provice basic
+operations for 3GPP (GSM, UMTS, LTE) or CDMA (CDMA1x, EV-DO) modems. If a given
+feature is not available in the modem, the specific interface will not be
+exported in DBus.
Plugins.
Plugins are loaded on startup, and must implement the MMPlugin interface. It
consists of a couple of methods which tell the daemon whether the plugin
-supports a port and to create custom MMModem implementations. It most likely
-makes sense to derive custom modem implementations from one of the generic
-classes and just add (or override) operations which are not standard. There's a
-fully working plugin in the plugins/ directory for Huawei cards that can be
+supports a port and to create custom MMBroadbandModem implementations. It most
+likely makes sense to derive custom modem implementations from one of the
+generic classes and just add (or override) operations which are not standard.
+There are multiple fully working plugins in the plugins/ directory that can be
used as an example for writing new plugins. Writing new plugins is highly
-encouraged!
-
-API.
-The API is open for changes, so if you're writing a plugin and need to add or
-change some public method, feel free to suggest it!
+encouraged! The plugin API is open for changes, so if you're writing a plugin
+and need to add or change some public method, feel free to suggest it!