blob: b1bba5ff01cd714d97b445a4b6dbcf981734fa4c (
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
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Plugin-specific Modems</title>
<meta name="generator" content="DocBook XSL Stylesheets V1.78.1">
<link rel="home" href="index.html" title="ModemManager Reference Manual">
<link rel="up" href="ref-overview.html" title="Part I. ModemManager Overview">
<link rel="prev" href="ch03s04.html" title="Disabling">
<link rel="next" href="ref-common-types.html" title="Part II. Common types and definitions">
<meta name="generator" content="GTK-Doc V1.18.1 (XML mode)">
<link rel="stylesheet" href="style.css" type="text/css">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
<table class="navigation" id="top" width="100%" summary="Navigation header" cellpadding="2" cellspacing="2"><tr valign="middle">
<td><a accesskey="p" href="ch03s04.html"><img src="left.png" width="24" height="24" border="0" alt="Prev"></a></td>
<td><a accesskey="u" href="ref-overview.html"><img src="up.png" width="24" height="24" border="0" alt="Up"></a></td>
<td><a accesskey="h" href="index.html"><img src="home.png" width="24" height="24" border="0" alt="Home"></a></td>
<th width="100%" align="center">ModemManager Reference Manual</th>
<td><a accesskey="n" href="ref-common-types.html"><img src="right.png" width="24" height="24" border="0" alt="Next"></a></td>
</tr></table>
<div class="chapter">
<div class="titlepage"><div><div><h2 class="title">
<a name="ref-overview-plugin-specific-modems"></a>Plugin-specific Modems</h2></div></div></div>
<p>
ModemManager plugins exist in order to handle all non-standard vendor-specific behaviour
that needs to get supported.
</p>
<p>
Plugins will provide their own Modem object implementations, usually subclassing the
generic <span class="structname">MMBroadbandModem</span> object. As previously explained, this
object implements every interface that may be exported by the Modem object in DBus; and
then, depending on the per-interface support checks, the interface will end up being
really exported or not.
</p>
<p>
Each interface defines every step to be run during the initialization, enabling or
disabling sequences. Then, the object implementing the interface may or may not provide
the implementation of such step. By default, the generic
<span class="structname">MMBroadbandModem</span> object implements already most of the steps
in the interfaces providing common features:
</p>
<div class="figure">
<a name="mm-modemmanager-interface-initialization-sequence"></a><p class="title"><b>Figure 2. Modem interface initialization sequence</b></p>
<div class="figure-contents"><div><img src="ModemManager-interface-initialization-sequence.png" alt="Modem interface initialization sequence"></div></div>
</div>
<br class="figure-break"><p>
Vendor-specific subclasses of <span class="structname">MMBroadbandModem</span> are then able to
either provide their own implementation of a given step (in the image below, a custom
implementation for capabilities checking); or even completely disable the step if they
know that there is no way to run it (in the image below, revision string loading is
removed).
</p>
<div class="figure">
<a name="mm-modemmanager-interface-initialization-sequence-subclassed"></a><p class="title"><b>Figure 3. Modem interface initialization sequence subclassed</b></p>
<div class="figure-contents"><div><img src="ModemManager-interface-initialization-sequence-subclassed.png" alt="Modem interface initialization sequence subclassed"></div></div>
</div>
<br class="figure-break"><p>
These subclass-able steps are all implemented as standard GIO asynchronous functions,
so subclassing a step involves implementing both the async method which receives the
input arguments to the action and the corresponding <code class="literal"><code class="function">_finish()</code></code> method
which provides the results of the action once the operation is ready.
</p>
<p>
It is worth noting that these steps and the asynchronous methods implementing them
don't assume that an AT port will be used to implement the real action. This means
that any other kind of port may be really used (e.g. QCDM or QMI) in the implementation,
or even that a static reply can be returned (e.g. Iridium modems will always report
"Iridium" as current OperatorName).
</p>
</div>
<div class="footer">
<hr>
Generated by GTK-Doc V1.18.1</div>
</body>
</html>
|
