Both the ModemManager daemon and the mmcli will now include `libmm-glib.h' only.
We also handle two new special `_LIBMM_INSIDE_MM' and `LIBMM_INSIDE_MMCLI'
symbols, which if included before the `libmm-glib.h' library allow us to:
* Don't include the libmm-glib high level API in the ModemManager daemon, as
the object names would clash with those in the core.
* Define some of the methods of helper objects to be included only if compiling
ModemManager daemon or the mmcli.
It's pointless to have libmm-common around, just merge it into libmm-glib and
make ModemManager depend on libmm-glib directly. At the end, the non-common
stuff in libmm-glib is really minimal.
The Firmware interface was highly based on 'slots' to identify the existing
firmware images; but that doesn't fit very well with the initial implementation
of the Firmware interface in QMI-based modems. In these modems the 'storage
index' is a property which is not available in all types of images (e.g. 'PRI'
images don't have it).
Therefore, instead of using a unique 'slot' identifier we'll just use the
'name' of the firmware as unique ID.
Also, currently skip the handling of 'available' images, and the method to
'Install()' new images, at least until we have one implementation defining what
to do with those.
Some Icera-based modems (e.g. Samsung/Icera Y3300/Y3400) may take a loong time
to run the power down command (see commit 5f1a1cf8). So, for these modems we
will fully skip the power down command run during initialization.
The power-down command defined by the plugin will be run *only* after having
checked for current and modem capabilities, as plugins (e.g. Sierra) may have
different commands for that depending on whether they are 3GPP or 3GPP2.
We do not reuse the 'modem_power_down' callback from the disabling sequence, as
some plugins really behave pretty badly with this (e.g. Samsung CFUN=4 may take
up to 30s to complete). So, we let plugins use the power-down command when
disabling but avoid launching it during init.
In order to ease the life for clients listening to the 'state-changed' signal,
the change in the 'state' property in the DBus interface skeleton is flushed
right away, before emitting 'state-changed'. By doing this we make sure that
the 'state-changed' callbacks in the clients are able to see exactly the same
current state in the modem proxy.
The `MMManager' is itself also a `GDBusObjectManagerServer'. If we create this
object after having fully acquired the bus name, the client application in the
other side of the bus could be trying to use the ObjectManager interface before
we actually exported it, which is wrong. Therefore, we need to make sure that
the Manager interfaces are all exported before the name is acquired.
