blob: f0d68dcc7611ab56666fae7f49e2da5bc1314fbf (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
<?xml version="1.0"?>
<!DOCTYPE part PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [
]>
<part id="ref-overview">
<title>ModemManager Overview</title>
<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.
</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.
</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.
</para>
</formalpara>
<formalpara>
<title>Plugins</title>
<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!
</para>
</formalpara>
</chapter>
<chapter id="ref-overview-states">
<title>State machine</title>
<para>
ModemManager implements support for each Modem by controlling their
behaviour following the steps given in the following state machine.
</para>
<figure id="mm-modemmanager-states">
<title>ModemManager states</title>
<graphic fileref="ModemManager-states.png" format="PNG"></graphic>
</figure>
<para>
The state machine of a modem can be summarized in 5 main sequences:
initialization, enabling, connection, disconnection and disabling.
</para>
<section>
<title>Initialization</title>
<para>
<!-- TODO -->
</para>
</section>
<section>
<title>Enabling</title>
<para>
<!-- TODO -->
</para>
</section>
<section>
<title>Connection</title>
<para>
<!-- TODO -->
</para>
</section>
<section>
<title>Disconnection</title>
<para>
<!-- TODO -->
</para>
</section>
<section>
<title>Disabling</title>
<para>
<!-- TODO -->
</para>
</section>
</chapter>
</part>
|
