| Age | Commit message (Collapse) | Author |
|---|
|
Some modems, e.g. Huawei E367, will probe first the QMI port and for some reason
it doesn't report a proper VID/PID so the Generic plugin is the one finally
accepting that port. When we probe the AT ports afterwards we already got the
Generic plugin as suggestion, and we end up not grabbing the proper primary and
secondary ports as we skipped the AT^GETPORTMODE reply.
So, from now on the Generic plugin is never suggested to other probes; except
for the case where we need the suggestion to finish a probing task which was
'deferred until suggested'.
Also, the device-level plugin can now be overwritten, if and only if, the
previously set plugin was the Generic one.
|
|
|
|
Ports being marked as unsupported should not be passed to the plugin specific
create_modem() or grab_port() methods.
|
|
If a port support task was deferred until suggested, do not assume that the
suggested plugin actually supports the port, instead re-launch support check.
This covers the cases where a net port appears in a modem which only supports
AT ports (e.g. Nokia case).
|
|
|
|
|
|
|
|
Instead of providing a method to get if a plugin is requesting to get sorted
last, we provide a way to comparing two plugins, compatible with the
GCompareFunc required in g_list_sort().
|
|
|
|
The plugin manager no longer needs to take care of keeping track of which probes
are being run and to which physical device they correspond, as the upper layer's
`MMDevice' already does this. This simplifies the internal logic quite a lot, as
we can now easily suggest plugins to the remaining port probes of the same
device directly.
|
|
|
|
We no longer need to query the plugin manager whether we're checking support for
a specific port, as the ports are now grabbed only once in the MMDevice, and
therefore we ensure that supports check is launched only once in the
PluginManager for that specific port.
Also, we no longer need to query the plugin manager whether we're checking
support for a given device, as the logic to check when all ports of the device
are probed is now maintained internally.
|
|
Effectively, we're now letting the kernel up to 2s to show all the ports of the
device, starting from the time where the first port is exposed.
|
|
The new `mm_plugin_manager_find_device_support()' will be an async method which
waits for ports to be added in the given `MMDevice'. As soon as all added ports
are probed, the device support check is considered finished.
|
|
already there
It may happen that we launch the supports task in the port AFTER having received
the suggestion.
|
|
If deferring tasks until result suggested, and we never got a suggestion, the
tasks may have been left deferred in loop forever. We now remove the defer
timeout in the case of waiting for suggestion, and ensure that we cancel tasks
if the last valid probing ended without best plugin found.
|
|
'net' ports will be supported as soon as there is another port reporting
successful support.
|
|
|
|
We chain up the Generic plugin created MMBroadbandModem objects within the
GDBusObjectManagerServer in MMManager, so that they get properly exported in
DBus.
|
|
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.
|
|
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.
|
|
There is little chance of having a PLUGINDIR which is not UTF-8, but it may
happen, and g_log() won't like it.
|
|
Ported the plugin finding and loading code from the MMManager object.
|
|
Looking for plugins and loading them will be done during the object creation,
so the operation may fail and we need to report it.
|
|
|
