On Fri, Dec 23, 2011 at 6:59 AM, Aleksander Morgado <[email protected]>wrote:
> Hey, > > 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. > > 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? When all ports of the modem get finally probed, the modem would get > initialized. If this initialization succeeds we would signal COMPLETED and > the probing-specific status would go back to IDLE if there are no other > devices being probed. If the initialization fails and we decide the modem > is not usable (e.g. when trying to check SIM PIN status we get a NO SIM > error), we would signal FAILED including the specific error. > I like this idea of providing an error when the modem is unusable. > > I think that with this new probing-related state we could improve a lot > the user experience, which right now is a bit "connect and wait for the > applet to hopefully show the device". > > Comments, other suggestions? > > -- > Aleksander > ______________________________**_________________ > networkmanager-list mailing list > [email protected] > http://mail.gnome.org/mailman/**listinfo/networkmanager-list<http://mail.gnome.org/mailman/listinfo/networkmanager-list> >
_______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
