| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
|
|
A new 'priv' pointer is added in the MMManager struct, which will contain the
address of the private structure.
|
|
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.
|
|
|
|
If the port is supported by the plugin, leave the probe in the internal HT until
the port gets grabbed afterwards.
|
|
|
|
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.
|
|
Instead of just a boolean, provide a MMPluginSupportsResult, so that we can pass
it as is during `supports_port_finish()'.
|
|
|
|
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.
|
|
|
|
Fixes compilation of the Port Probe object.
|
|
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 boolean property to specify whether they can handle
QCDM ports, and therefore probing for them is needed.
|
|
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);
|
|
properties
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We will initially probe for AT support in the port.
|
|
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()'.
|
|
Each port probe is always associated to one specific port.
|
|
|
|
All plugin handling and port support checks now done by the Plugin Manager.
|
|
The new mm_plugin_manager_is_finding_port_support() allows to check whether the
Plugin Manager is looking for support in a specific port.
The new mm_plugin_manager_is_checking_device_support() allows to check whether
the Plugin Manager is looking for support in any port of a given device.
|
|
The newly launched support check will start probing with the suggested plugin
right away.
|
|
As soon as the first support check of a port in a given device finishes with a
valid best plugin and level > 0, propagate the result to other support tasks
corresponding to ports in the same physical device.
Previously, this propagation of support check results was only done once the
port was grabbed by a plugin, not just when the plugin reported that it
supported it. This change in behaviour isn't probably a big deal, as there
should not be any case where a plugin says it supports a port and then cannot
grab it.
|
|
We will keep a reference to each of the support checks currently in progress,
grouped by physical device path. The stored SupportsInfo structs as well as
the support check operations, are guaranteed to be kept valid as long as the
Plugin Manager exists. Or in other words, the Plugin Manager cannot be disposed
if there is still an ongoing supports check operation.
|
|
The new `mm_plugin_manager_find_port_support()' method requests the Plugin
Manager to iterate over the list of plugins internally handled, launching
supports task for the given port in each of them.
The method is fully asynchronous, and the result can be retrieved with
`mm_plugin_manager_find_port_support_finish()' once the operation is ready.
|
