
If we only expect a single AT port, we'll cancel all remaining AT port probings in the other ports, as soon as we get the first one.
121 lines
5.0 KiB
Plaintext
121 lines
5.0 KiB
Plaintext
|
|
|
|
--------------------------------------------------------------------------------
|
|
* Documentation: libmm-glib
|
|
|
|
libmm-glib should have its own gtk-doc based documentation setup in
|
|
docs/reference. This task involves setting up the gtk-doc build under docs/,
|
|
as well as including all missing gtk-doc comments in the sources.
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
* Documentation: libmm-common
|
|
|
|
libmm-common is the common library used both by libmm-glib and the ModemManager
|
|
daemon. Some of its bits must be considered internal, like the server-side
|
|
specific code generated by gdbus-codegen; but lots of other bits are to be
|
|
considered public and therefore documented with gtk-doc. This task involves
|
|
setting up the gtk-doc build under docs/, as well as including all missing
|
|
gtk-doc comments in the sources.
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
* Documentation: debugging tips
|
|
|
|
Provide a section for debugging tips in the ModemManager documentation.
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
* GObject introspection
|
|
|
|
Either with libmm-common or libmm-glib, we should provide GObject Introspection
|
|
support for the libraries. libmm-glib is just a small layer on top of
|
|
libmm-common, so maybe the introspection can be done at libmm-common level
|
|
directly.
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
* Firmware
|
|
|
|
ModemManager should implement the Firmware interface if modems allow to change
|
|
firmware on-the-fly.
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
* Contacts
|
|
|
|
ModemManager should implement the Contacts interface if modems allow to query
|
|
and manipulate the contacts information stored in SIM or device.
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
* GPS Location
|
|
|
|
ModemManager should expose GPS-based location information if the modem exposes
|
|
a port that shows NMEA (or equivalent) traces.
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
* Probing time mitigation
|
|
|
|
Probing time may end up being quite long if we're checking support of a modem
|
|
which exposes multiple ports. It is specially bad if the modem exports a port
|
|
which is neither AT nor QCDM, as we use all our probing attempts before we can
|
|
export the modem in DBus (we do wait to get all ports probed before running the
|
|
initialization sequence, as we want to use the primary port for that always).
|
|
|
|
Therefore, looking for ways to mitigate probing time in the specific bad cases
|
|
is a good way of minimizing this problem. Some ideas:
|
|
|
|
** If one AT probing suceeds, don't allow timeouts in remaining ports when
|
|
probing for AT.
|
|
|
|
--------------------------------------------------------------------------------
|
|
* AT+CMUX & Serial multiplexing
|
|
|
|
Some modes allow to use virtual channels set up over one single serial
|
|
interface, as defined at 3G TS 27.010. This allows devices with one single port
|
|
to get a virtual secondary port for AT commands while in connected mode, for
|
|
example to update the signal quality value or check registration status.
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
* Additional minor enhancements, fixes and general brainstorm
|
|
|
|
** Per-device log function? Something like mm_modem_log() and
|
|
mm_modem_port_log(), so that we include automatically the modem number
|
|
(and port name) in each log line.
|
|
|
|
** Do we really need function name, filename and line in the debug log?
|
|
|
|
** In the default MMBroadbandModem, check how we can know if we're sitting in
|
|
a rev0, revA or revB CDMA network. We need to expose the exact access
|
|
technology in the interface.
|
|
|
|
** Fix object names to show proper inheritance? For example:
|
|
- MMPort, MMPortSerial, MMPortSerialAt, MMPortSerialQcdm
|
|
- MMModem (instead of MMBaseModem), MMModemBroadband, MMModemPots
|
|
- MMBearer, MMBearerBroadband, MMBearerPots
|
|
|
|
** MMPlugin: do we really need a separate interface for the plugin? Why not
|
|
just assume that all plugins need to provide objects subclassing
|
|
MMPluginBase?
|
|
|
|
** Test cases for CIEV responses.
|
|
|
|
** When a modem gets initialized for the first time it goes into DISABLED, but
|
|
it may really happen that the modem isn't really disabled (in low-power
|
|
mode, those which support it). Currently if you want to ensure that the
|
|
modem goes into low-power mode once detected, you need to enable the modem
|
|
and just after that disable it, so that the proper CFUN=0/4/7 is run. We
|
|
could probably run the disabling sequence, including power-off steps, as
|
|
soon as we end the initialization sequence.
|
|
|
|
** When a 3GPP modem is disabled, we run AT+CREG=0. That will just disable the
|
|
automatic registration checks and unsolicited messages, the modem will
|
|
still be registered in the network. AT+COPS=2 is the one doing manual
|
|
unregistration from the network, and we should probably include such step
|
|
in the 3GPP disabling sequence.
|
|
|
|
** serial-parsers: convert the v1 parser to a GObject.
|