| |
| |
| -------------------------------------------------------------------------------- |
| * 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. |