115 lines
4.8 KiB
Plaintext
115 lines
4.8 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.
|
|
|
|
|
|
--------------------------------------------------------------------------------
|
|
* 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.
|