api,enums: implement all enums and flags from the new API

This commit is contained in:
Aleksander Morgado
2012-03-15 14:14:17 +01:00
parent 8763576a34
commit 4cdbaa5de3
8 changed files with 455 additions and 743 deletions
@@ -247,149 +247,6 @@
-->
<property name="Location" type="a{uv}" access="read" />
<!-- ENUMS -->
<tp:flags name="MM_MODEM_LOCATION_CAPABILITIES" value-prefix="MM_MODEM_LOCATION_CAPABILITY" type="u">
<tp:flag suffix="UNKNOWN" value="0x0">
<tp:docstring><p>Unknown or no capabilties.</p></tp:docstring>
</tp:flag>
<tp:flag suffix="GPS_NMEA" value="0x1">
<tp:docstring>
<p>For capability reporting, indicates the device is capable of
providing GPS NMEA-format location information.</p>
<p>For location reporting, devices supporting this capability return
a string containing one or more NMEA sentences (D-Bus signature 's').
The manager will cache the most recent NMEA sentence of each type for
a period of time not less than 30 seconds. When reporting multiple
NMEA sentences, sentences shall be separated by an ASCII Carriage
Return and Line Feed (&lt;CR&gt;&lt;LF&gt;) sequence.
</p>
<p>
For example, if the device sends a $GPRMC sentence immediately
followed by a $GPGGA sentence, the reported location string would be
(where of course the &lt;CR&gt;&lt;LF&gt; is replaced with the actual
ASCII CR (0x0D) and LF (0x0A) control characters):
<pre>
$GPRMC,134523.92,V,,,,,,,030136,,,N*73&lt;CR&gt;&lt;LF&gt;$GPGGA,,,,,,0,00,0.5,,M,0.0001999,M,0.0000099,0000*45
</pre>
If the device sends a new $GPRMC three seconds later, the new $GPRMC
replaces the previously received $GPRMC sentence, and the updated
string would be:
<pre>
$GPRMC,134526.92,V,,,,,,,030136,,,N*76&lt;CR&gt;&lt;LF&gt;$GPGGA,,,,,,0,00,0.5,,M,0.0001999,M,0.0000099,0000*45
</pre>
If the device then sends a $GPGSA sentence about 5 seconds later, the
$GPGSA sentence is added to the string (since no $GPGSA sentence was
previously received in this session), the updated string would be:
<pre>
$GPRMC,134526.92,V,,,,,,,030136,,,N*76&lt;CR&gt;&lt;LF&gt;$GPGGA,,,,,,0,00,0.5,,M,0.0001999,M,0.0000099,0000*45&lt;CR&gt;&lt;LF&gt;$GPGSA,A,1,,,,,,,,,,,,,1.1,0.5,1.0*34
</pre>
The manager may discard any cached sentences older than 30 seconds.
</p>
<p>This allows clients to read the latest positioning data as soon as
possible after they start, even if the device is not providing
frequent location data updates.
</p>
</tp:docstring>
</tp:flag>
<tp:flag suffix="GSM_LAC_CI" value="0x2">
<tp:docstring>
<p>For capability reporting, indicates the device is capable of
providing GSM Location Area Code/Cell ID location information.</p>
<p>For location reporting, devices supporting this
capability return a string in the format "MCC,MNC,LAC,CI" (without the
quotes of course) where the following applies:</p>
<ul>
<li>
MCC is the three-digit ITU E.212 Mobile Country Code of the
network provider to which the mobile is currently registered.
This value should be the same MCC as reported by the
org.freedesktop.Modem.Gsm.Network.GetRegistrationInfo() method's
returned "operator code" argument.
e.g. "310"
</li>
<li>
MNC is the two- or three-digit GSM Mobile Network Code of the
network provider to which the mobile is currently registered.
This value should be the same MCC as reported by the
org.freedesktop.Modem.Gsm.Network.GetRegistrationInfo() method's
returned "operator code" argument.
e.g. "26" or "260"
</li>
<li>
LAC is the two-byte Location Area Code of the base station with
which the mobile is registered, in upper-case hexadecimal format
without leading zeros, as specified in 3GPP TS 27.007 section
10.1.19. e.g. "84CD".
</li>
<li>
CI is the two- or four-byte Cell Identifier with which the mobile
is registered, in upper-case hexadecimal format without leading
zeros, as specified in 3GPP TS 27.007. e.g. "2BAF" or "D30156".
</li>
</ul>
<p>The entire string may only be composed of the ASCII digits [0-9],
the alphabetical characters [A-F], and the comma (,) character. No
other characters are allowed. For example: "310,260,8BE3,2BAF" or
"250,40,CE00,1CEAD8F0".</p>
<p>If any of these four items (MCC,MNC,LAC,CI) is unknown or the
mobile is not registered with a network, then the GSM_LAC_CI location
information item should not be provided as a returned value from the
GetLocation() method or in the Location property.</p>
</tp:docstring>
</tp:flag>
<tp:flag suffix="GPS_RAW" value="0x4">
<tp:docstring>
<p>For capability reporting, indicates the device is capable of
providing raw GPS information using a series of defined key/value
pairs.</p>
<p>For location reporting, devices supporting this
capability return a D-Bus dict (signature a{sv}) mapping well-known
keys to values with defined formats. The allowed key/value pairs
and their formats are:</p>
<table>
<tr><th>Key</th><th>Value Type</th><th>Value contents</th><th>Example</th></tr>
<tr>
<td>latitude</td>
<td>d</td>
<td>Latitude in Decimal Degrees (positive numbers mean N quadrasphere, negative mean S quadrasphere)</td>
<td>38.889722 (ie, 38d 53' 22" N)</td>
</tr>
<tr>
<td>longitude</td>
<td>d</td>
<td>Longitude in Decimal Degrees (positive numbers mean E quadrasphere, negative mean W quadrasphere)</td>
<td>-77.008889 (ie, 77d 0' 32" W)</td>
</tr>
<tr>
<td>altitude</td>
<td>d</td>
<td>Altitude above sea level in meters</td>
<td>33.5</td>
</tr>
<tr>
<td>horiz-velocity</td>
<td>d</td>
<td>Horizontal velocity in meters-per-second</td>
<td>.5</td>
</tr>
<tr>
<td>vert-velocity</td>
<td>d</td>
<td>Vertical velocity in meters-per-second</td>
<td>.01</td>
</tr>
</table>
<p>The 'latitude' and 'longitude' keys are required; other keys are
optional.</p>
</tp:docstring>
</tp:flag>
</tp:flags>
</interface>
</node>