Users will be able to enable or disable modems using the DBus interface. We will
chain up the `Enable(boolean)' call from the DBus interface to these new methods
in the base modem class.
Basically, a replacement of the MMModemBase type, being prepared to handle
multimode devices.
This object derives from a MmGdbusObjectSkeleton, which makes it suitable to be
controlled within the GDBusObjectManagerServer.
This setup, allows:
- Running a single command and processing its result.
- Running a set of N commands, providing a global result after all have
been executed.
- Running a set of N commands out of M (N<M), where the global result is
obtained without having executed all configured commands. This is useful
when probing, for example.
The MMManager object creation may fail due to environment reasons (i.e. no
plugins found, or problems exporting DBus interfaces), so we can use the
initable interface to properly handle those situations.
The MMManager object now derives from the gdbus-codegen-generated
MmGdbusOrgFreedesktopModemManager1Skeleton object, and implements the handlers
for the SetLogging() and ScanDevices() DBus methods.
The main program is also modified to be based on GDBus.
Support checks are fully asynchronous and result is always reported when the
check is considered ready, so in-progress replies to
`mm_plugin_supports_port_finish()' don't make any sense.
There is no single case where more than one plugin may end up wanting to support
a given port, and therefore there is no need to report the numeric support level
when reporting SUPPORTED.
Some devices support 'net' devices, which cannot be AT or QCDM probed.
If the port being checked for support corresponds to an already existing modem,
the port will be reported as SUPPORTED.
If this is the first port of the modem being checked for support, we will just
DEFER the support check until we get a modem created.
If the plugin does a Vendor ID check and it passes, it doesn't need Vendor
string probing.
If the plugin does a Vendor ID check and it fails:
- If Vendor strings reported, it needs Vendor probing.
- If Vendor strings not reported, fail as unsupported.
If the plugin does a Product ID check and it passes, it doesn't need Product
string probing.
If the plugin does a Product ID check and it fails:
- If Product strings reported, it needs Product probing.
- If Product strings not reported, fail as unsupported.
Once probing is finished, the plugin will check whether the port is supported
or not based on the following filters:
- Capabilities
- Reported Vendor string
- Reported Product string
Before any real probing is launched in the port, the plugin will check whether
it can skip the request based on the following filters:
- Subsystems
- Drivers
- udev-reported Vendor ID
- udev-reported Product ID
- udev-reported Tags
The previous 'MMPluginBaseSupportsTask' object is more or less equivalent to the
new `MMPortProbe' in terms of what information it contains. The main difference
being that the new `MMPortProbe' object handles internally the whole probing
flow as needed: only the needed probing sequences are done. For example, vendor
or product string probing will only be performed if a plugin requests it.
The plugins can set this property to filter support check requests by the
availability of a given udev tag in the port. The value given to the property
should be a NULL-terminated array of C strings, e.g.:
const gchar *tags[] = { "ID_MM_X22X_TAGGED", NULL };
Aleksander Morgado
Aleksander Morgado