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 };
The plugins can set this property to filter support check requests by physical
device driver. The value given to the property should be a NULL-terminated array
of C strings, e.g.:
const gchar *drivers[] = { "qcserial", NULL };
The plugins can set this property to provide a custom value for the send delay
used for characters sent to the AT port during probing.
The value given to the property should be a guint64 specifying the delay in
microseconds.
The plugins can set this property to filter support check requests by probed
capabilities.
The value given to the property should be a guint built as a mask of
MM_PORT_PROBE_CAPABILITY flags, e.g.:
const guint capabilities = (MM_PORT_PROBE_CAPABILITY_GSM |
MM_PORT_PROBE_CAPABILITY_CDMA);
The plugins can set these properties to filter support check requests by
AT-reported Vendor string and Product string.
The value given to the properties should be a NULL-terminated array of strings,
e.g.,
static const gchar *vendor_strings[] = { "cinterion" , NULL };
The plugins can set this property to provide custom initialization commands that
should be issued to the modem before real probing starts.
The value given to the property should be an array of MMPortProbeAtCommand
variables finished with a last one exposing a NULL command, e.g.:
static gboolean
parse_init (const gchar *response,
const GError *error,
GValue *result,
GError **result_error)
{
if (error)
return FALSE;
/* If we didn't get any error, it is an AT port */
g_value_init (result, G_TYPE_BOOLEAN);
g_value_set_boolean (result, TRUE);
return TRUE;
}
static gboolean
parse_init_last (const gchar *response,
const GError *error,
GValue *result,
GError **result_error)
{
g_value_init (result, G_TYPE_BOOLEAN);
/* On last error, report as not being an AT port */
g_value_set_boolean (result, error ? FALSE : TRUE);
return TRUE;
}
static const MMPortProbeAtCommand custom_init[] = {
{ "ATE1 E0", parse_init },
{ "ATE1 E0", parse_init },
{ "ATE1 E0", parse_init_last },
{ NULL }
};
The plugins can set these properties to filter support check requests by
udev-reported Vendor ID and Product ID.
The value given to the properties should be a 0-terminated array of guint16s,
e.g.,
static const guint16 vendor_ids[] = { 0x0421 , 0 };
The plugins can set this property to filter support check requests by subsystem.
The value given to the property should be a NULL-terminated array of C strings,
e.g.:
const gchar *subsystems[] = { "tty", NULL };
Whenever a plugin has probed for some information in a given port, that data
should be available for any other plugin wanting it during its own probing
process. This new cache of Port Probe results allows to easily retrieve the
already probed information.
The new `MMPortProbeAtCommand' type defines what command will be sent to the
serial AT port, and also a response processor method to parse the string
returned by the port.
The response processor gets as input either the text reply string or an error,
and it should give as output either a GValue (type depends on the probing kind
being done) or a new error (which will force the whole probing process to be
aborted.
The new `mm_port_probe_cancel()' will cancel the probing operation currently in
progress, if any. Note that we don't need to pass any argument to specify which
operation to cancel, as there can only be one.
The new method `mm_port_probe_run()' will run the whole probing process
asynchronously. Result of the probing can be later obtained with
`mm_port_probe_run_finish()'.
