Commit graph

6 commits

Author SHA1 Message Date
Thomas Haller
6fb917178a dbus: deprecated NM specific PropertiesChanged signals
Nowadays, users should use the standard "PropertiesChanged" signal
on "org.freedesktop.DBus.Properties" interface.
2016-09-02 20:13:36 +02:00
Lubomir Rintel
a8e8e76641 dbus: fix up the XML formatting
The conversion script didn't do a very good job. It got fired.
2016-04-05 14:37:51 +02:00
Lubomir Rintel
2ae34aef9f dbus: correct the links to types
gdbus-codegen is not smart enough to understand #Type, include raw
docbook directly.
2016-04-05 14:37:51 +02:00
Lubomir Rintel
6e2b188361 dbus: convert the annotations to gtk-doc blocks 2016-04-05 14:37:51 +02:00
Lubomir Rintel
618373a14f dbus: use the annotations for documentation
gdbus only understands those (and gtk docstrings, which we should eventually
use) when generating the documentation.
2016-03-26 11:28:19 +01:00
Dan Williams
2140dad5e0 core: consolidate mobile broadband device types
These days more and more devices are showing up that support a
number of different access technology families in the same hardware,
like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM),
Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra
320U (GSM and LTE), etc.  The previous scheme of having device
classes based on access technology family simply cannot handle
this hardware and attempting to add LTE to both the CDMA and GSM
device classes would result in a bunch of code duplication that
we don't want.  There's a better way...

Instead, combine both CDMA and GSM device classes into a generic
"Modem" device class that provides capabilities indicating what
access technology families a modem supports, and what families
it supports immediately without a firmware reload.  (Gobi devices
for example require a firmware reload before they can switch
between GSM and CDMA).  This provides the necessary flexibility
to the client and allows us to keep the API stable when the
same consolidation change is made in ModemManager.

The current code doesn't yet allow multi-mode operation internally,
but the API is now what we want it to be and won't need to be
changed.
2011-02-25 10:16:17 -06:00