[RFC] New probing-related status in ModemManager
- From: Aleksander Morgado <aleksander lanedo com>
- To: Network Manager <networkmanager-list gnome org>
- Subject: [RFC] New probing-related status in ModemManager
- Date: Fri, 23 Dec 2011 12:59:53 +0100
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.
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.
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 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]