Re: [RFC] New probing-related status in ModemManager

[Aleksander Morgado <aleksander lanedo com>]

Hey Jason,

>     One of the things that annoys me when using ModemManager is that
>     whenever I plug in a modem, I need to wait for the modem to get all
>     ports probed before I can see the NM applet updated with the new
>     broadband-related menu elements. In the worst case, where the modem
>     just returns errors to probing, I may end up waiting forever unless
>     I check syslog.
> 
>     This long time to wait is mainly related to the fact that we probe
>     all ports of the modem trying to send several AT commands, or even
>     trying to see if the port is QCDM and such.
> 
>     For example:
>      * I plugin a Huawei modem which exposes lots of ports.
>      * Probing is started in all of them in parallel
>      * The good AT ports reply instantly and probing ends quite fast for
>     them.
>      * Non-AT ports go on with the probing, timing out in each AT command.
>      * Once all non-AT ports get timed out in the last command from the
>     probing sequence, we successfully initialize and export the modem,
>     as we got valid AT ports previously.
>      * If for whatever reason the probing completely fails, we don't
>     really notify it to the user in any way.
> 
>     This whole sequence may take up to 10-20s to complete.
> 
> 10-20 seconds is a long time to wait, especially on suspend/resume cycles. 
> 

Yes, it is. Doing the whole probing of my Nokia phone takes ~18s with MM
from git master, due to getting a ttyACM1 port detected which is neither
an AT port nor a QCDM port. The effect is specially bad because the
Nokia plugin has an init command tried up to 3 times, plus then 6
commands from AT capability checks, and all of them get timed out. The
same modem with the 06-api branch needs ~9s, as the init command sent to
the modem is used also for AT support check, and therefore we just have
the init command timed out 3 times. It's probably worth modifying this a
bit further and i.e. just allow the modem to time out once in the init
command, at least for the case of the Nokia plugin, and we can possibly
do the same for other plugins, leaving the long (up to 10s) probing just
in the generic plugin.

> 
>     The new 06-api branch tries to minimize this by early trying to
>     probe just for AT support; and more improvements can even be done
>     (like, if we got an AT port already, just allow max one AT command
>     timeout in the other ports, just an idea). But, in order to minimize
>     the effect of probing ports which will end up timing out and not
>     being used, I think we could try to show to the user some status
>     that the device was detected and probing is ongoing. Even if the
>     whole probing of the modem takes 10s, the user could see an
>     in-progress icon, or even a notification that a modem was detected
>     and support is being checked.
> 
>     So, a probing-specific ModemManager status could be of help here:
>      MM_PROBING_STATUS_IDLE,
>      MM_PROBING_STATUS_LAUNCHED,
>      MM_PROBING_STATUS_ONGOING, (device specific)
>      MM_PROBING_STATUS_FAILED, (device specific)
>      MM_PROBING_STATUS_COMPLETED (device specific)
> 
>     Whenever a new modem is connected and probing launched, or when a
>     re-scan of modems is started, we would go to the LAUNCHED state.
> 
>     As soon as we create the Modem object once the first valid port is
>     probed, we would go to the ONGOING state. In this ONGOING state we
>     already have enough modem-specific information, like Vendor/Product
>     ID, but the modem is not yet exported. We could signal that
>     information so that the user gets a "Initializing support for modem
>     XXX" message as soon as possible, and at least she knows that
>     something is going on with the newly connected device.
> 
> Is there no way to associate the additional ports with the first valid
> port without waiting for a full 10 second timeout? And no way to figure
> out via the OS and the modem-specific information what the ports are
> used for other than sending down AT commands that may fail?
> 

As Dan points out in the other email, we can tag ports in udev if we
know how they will behave based on USB product+vendor ID, but this won't
always work.


-- 
Aleksander