diff options
| -rw-r--r-- | README | 44 | ||||
| -rw-r--r-- | docs/reference/api/ModemManager-overview.xml | 38 |
2 files changed, 42 insertions, 40 deletions
@@ -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! diff --git a/docs/reference/api/ModemManager-overview.xml b/docs/reference/api/ModemManager-overview.xml index 751dc687..7dad85a2 100644 --- a/docs/reference/api/ModemManager-overview.xml +++ b/docs/reference/api/ModemManager-overview.xml @@ -8,30 +8,31 @@ <chapter id="ref-overview-introduction"> <title>Introduction</title> <para> - ModemManager provides 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...). </para> <formalpara> <title>Using</title> <para> ModemManager is a system daemon and is not meant to be used directly from - the command line. However, a command line client (mmcli) is provided, which - may be used to test the different functionality provided during plugin - development. + 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. </para> </formalpara> <formalpara> <title>Implementation</title> <para> 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 are - DBus-interface specific GInterfaces, which should be implemented by any device - specific implementation. There is a generic MMBroadbandModem implementation that - provides a generic implementation of the most common operations in both GSM and - CDMA modems. + 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. </para> </formalpara> <formalpara> @@ -39,10 +40,13 @@ <para> 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 modem 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. Writing - new plugins is highly encouraged! + 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! 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! </para> </formalpara> </chapter> |