aboutsummaryrefslogtreecommitdiff
path: root/docs/reference
AgeCommit message (Collapse)Author
2019-10-28docs,libmm-glib: provide per-version indicesAleksander Morgado
2019-10-28docs,api: rework how indices are exposed in docsAleksander Morgado
Use <chapter> so that all per-version indices are included in the docs.
2019-10-27libmm-glib,pco: mm_pco_list_add() is not part of the APIAleksander Morgado
This method is used by the daemon to modify the GList of MMPco objects, the client should not need to use this method for anything.
2019-10-24docs,libmm-glib: add missing references to the 'emergency numbers' property ↵Aleksander Morgado
methods
2019-10-24docs,api: add missing reference to ID_MM_PORT_TYPE_AUDIOAleksander Morgado
2019-10-24docs,api: provide per-version indicesAleksander Morgado
2019-10-17voice,api: new 'EmergencyOnly' boolean flagAleksander Morgado
This new flag allows users of the API to know whether general purpose voice calls are allowed or otherwise only voice calls to the registered emergency numbers should be performed. ModemManager won't really do any distinction between emergency and non-emergency calls at this point, this flag is just an early indication for the user of the API that no normal voice call should be attempted.
2019-09-22docs,libmm-glib: add missing references to call waiting query/setupAleksander Morgado
2019-08-29udev: remove ID_MM_PLATFORM_DRIVER_PROBE tagAleksander Morgado
This tag is completely redundant because users can whitelist the platform TTY ports to use with the more generic ID_MM_DEVICE_PROCESS tag, which is part of the explicit whitelist filter rule.
2019-08-29udev: rename ID_MM_DEVICE_MANUAL_SCAN_ONLY to ID_MM_TTY_MANUAL_SCAN_ONLYAleksander Morgado
The udev tag that allows flagging devices that MAY be modems (e.g. USB<->RS232 adapters) is only applicable to TTY devices, so explicitly specify that in the tag name as well.
2019-08-29udev: repurpose ID_MM_DEVICE_IGNORE and new MM_FILTER_RULE_EXPLICIT_BLACKLISTAleksander Morgado
Until now the ID_MM_DEVICE_IGNORE udev tag was being used in the internal blacklist of devices shipped by ModemManager when running in either DEFAULT or PARANOID filter modes. The name of the tag is extremely misleading because it doesn't really make the full device be ignored, the tag only applied to TTY ports. This commit repurposes the tag so that it applies to ANY kind of port (e.g. TTY, NET, cdc-wdm...) and also to any kind of filter type (i.e. also applicable in STRICT mode). The internal blacklist shipped by ModemManager, which should NOT be used in STRICT mode, uses a new tag name, ID_MM_TTY_BLACKLIST. The new ID_MM_DEVICE_IGNORE tag is therefore much more usable and its name is really meaningful. If there are users or third-party projects adding their own udev rules with the ID_MM_DEVICE_IGNORE tag name, they should have no problem as the new rule is more restrictive than the old one.
2019-08-29docs: untabifyBen Chan
2019-07-11api,call: new JoinMultiparty() and LeaveMultiparty() methodsAleksander Morgado
2019-07-11api,call: new Multiparty boolean propertyAleksander Morgado
It will be set to TRUE if this call is part of a multiparty call.
2019-07-11api,call: new Deflect() methodAleksander Morgado
This method allows deflecting an incoming or waiting call to a different number.
2019-07-11api,voice: new Transfer() methodAleksander Morgado
This method will join all active and held calls into a single multiparty call, and then request the network to terminate the call on the subscriber's end and transfer the control of the call to the parties that are still in the call.
2019-07-11api,voice: new HangupAll() methodAleksander Morgado
This method will terminate all ongoing calls.
2019-07-11api,voice: new HoldAndAccept() methodAleksander Morgado
This method will put the currently active call on hold, and right away accept the next available call. The user of the API does not need to specify explicitly which is the next call to accept, because that is decided automatically: * If there is any waiting call, it will accept it right away. * If there is no waiting call but there is a held call, it will make the held call active again.
2019-07-11api,voice: new HangupAndAccept() methodAleksander Morgado
This method will hangup the currently active call and right away accept the next available call. The user of the API does not need to specify explicitly which is the next call to accept, because that is decided automatically: * If there is any waiting call, it will accept it right away. * If there is no waiting call but there is a held call, it will make the held call active again.
2019-07-02docs: add deprecated items to sections fileAleksander Morgado
2019-04-02api,modem: new 'CarrierConfigurationRevision' propertyAleksander Morgado
Which reports the version of the currently active carrier configuration. We also update the firmware 'version' reported in the firmware settings so that carrier-specific upgrades can be performed (e.g. when the firmware stays the same but the MCFG is updated).
2019-04-02iface-modem: new carrier config supportAleksander Morgado
During initialization phase we will allow querying the modem for the details of which carrier-specific configuration is being used, and will expose a description string in the API. In addition to showing the current configuration, we will also allow automatically switching the configuration based on the SIM card detected in the device. In order to allow this, plugins/modems will need to provide the expected mapping between carrier config description and MCCMNC. This mapping cannot be generic, because different manufacturers may use different description strings.
2019-01-11build: update copyright years to 2019Aleksander Morgado
2019-01-03api,manager: new InhibitDevice() methodAleksander Morgado
This new method allows users of the ModemManager API to take full control of a given device. Unlike other operations in the API, the inhibition is maintained as long as the caller exists in the bus, or until the same caller uninhibits the device. https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/98
2019-01-03api,firmware: MMModemFirmwareUpdateMethod as flags, not enumAleksander Morgado
Devices may require/support more than one update method, so instead of reporting the method as a single enum value, use a set of flags instead.
2019-01-03api,firmware: expose firmware versionAleksander Morgado
2019-01-03api,firmware: expose device idsAleksander Morgado
2019-01-03api,firmware: new UpdateSettings propertyAleksander Morgado
2018-12-17docs,libmm-glib: update copyrightAleksander Morgado
2018-12-10docs,libmm-glib: add missing methods for the Version propertyAleksander Morgado
2018-12-07api,modem-3gpp: new 'SetInitialEpsBearerSettings' methodAleksander Morgado
This method allows users to modify the settings used during the initial LTE attach procedure.
2018-12-07api,modem-3gpp: new 'InitialEpsBearerSettings' propertyAleksander Morgado
This property shows the settings stored in the device to be used during the initial LTE attach procedure.
2018-12-07api,modem-3gpp: new 'InitialEpsBearer' propertyAleksander Morgado
This property contains the DBus path of a Bearer object of type MM_BEARER_TYPE_DEFAULT_ATTACH, which is automatically exposed by the modem when registered in the LTE network. Unlike standard bearer objects created by the user, this bearer won't allow any connection/disconnection request, as its status is bound to the LTE registration exclusively. The bearer settings exposed by the object include the APN details that have been used during the initial packet network attach, which may be defined by modem settings (e.g. if previously configured in the firmware which APN to use for the given SIM card operator) or by the network itself (e.g. if none configured, or if a network override is required as when roaming). The bearer object will be created as soon as the LTE attach status details are known, and only while the modem is enabled. The implementation allows modems to update the LTE attach status details during runtime, so the bearer object with the settings may be recreated during runtime as well.
2018-12-07api,bearer: new 'BearerType' propertyAleksander Morgado
Until now we have only allowed to use and setup 'default bearers' (in 4G) or 'primary contexts' (in 2G/3G). We can define a couple of additional bearer types, though: * The 'dedicated bearers' (in 4G) or 'secondary contexts' (in 2G/3G), which are associated to a specific default/primary one, but which provide specific QoS settings configured via traffic flow templates. * The 'initial default EPS bearer', which is a special case of default bearer in LTE, which is automatically created and connected when the modem is registered in the LTE network. This commit introduces a new 'MMBearerType' enumeration that will be associated to each bearer through a 'BearerType' property in the org.freedesktop.ModemManager1.Bearer interface, showing what kind of bearer/context this is. By default, right now, all bearer objects created are 'default' bearers.
2018-12-04api,manager: new 'Version' propertyAleksander Morgado
This string shows the runtime version of the ModemManager daemon. https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/94
2018-11-12doc,libmm-glib: mm_pco_new() is not part of public APIAleksander Morgado
2018-11-12docs,libmm-glib: flag as private the mm_location_3gpp_reset() methodAleksander Morgado
2018-11-12docs: remove duplicated mm-call-audio-format sectionAleksander Morgado
2018-10-27docs: add missing MMCallAudioFormat reference in docsAleksander Morgado
2018-10-27doc: fix multiple missing referencesAleksander Morgado
2018-10-16api/libmm-glib/cli: add AudioPort and AudioFormat properties to the Call objectDan Williams
2018-09-25udev: define all generic tags as symbolsAleksander Morgado
This prevents errors due to nasty typos in the strings. We define all symbols in a single header file that is NOT considered part of the API, as there is no need for MM clients to know about these tags code-wise. These tags are only meaningful when associated to devices in udev. Information of each tag is included in the general API documentation. https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/88
2018-08-21api: support location assistance dataAleksander Morgado
Sometimes SUPL-server based A-GPS is not possible, e.g. if the module doesn't have Internet connectivity. In such cases, the modem may support injecting additional "assistance data" that may be downloaded from the Internet using external means (e.g. WiFi), in order to keep having a quick time to first fix. We now support using this location assistance data, with the following new API elements: * A new mask of supported assistance data types is provided in the SupportedAssistanceData property. * A new list of URLs from where the aassistance data may be downloaded is also provided in a new AssistanceDataServers property. * A new InjectAssistanceData() method is provided, to perform the data injection in the module once it's been downloaded to the host system.
2018-08-18modem-3gpp: add 'Pco' property to Modem3gpp interfaceBen Chan
This patch adds a 'Pco' property to the Modem3gpp interface for tracking PCOs that the modem has received from the network.
2018-08-18libmm-glib: add MMPco for handling raw PCO dataBen Chan
2018-03-13docs: add missing reference to mm_modem_3gpp_get_eps_ue_mode_operation()Aleksander Morgado
2018-03-13docs: always rebuild libmm-glib typesAleksander Morgado
So that we don't forget to add new types here manually... (e.g. MMBearerStats)
2018-01-25*: Spelling fixesVille Skyttä
2018-01-20modem-3gpp: allow loading and changing EPS UE mode of operationAleksander Morgado
The UE modes of operation for LTE are defined in 3GPP TS 24.301 (e.g. section 4.3 in v10.3.0): * PS mode 1: EPS only, 'voice centric' * PS mode 2: EPS only, 'data centric' * CS/PS mode 1: EPS and non-EPS, 'voice centric' * CS/PS mode 2: EPS and non-EPS, 'data centric' The mode specifies, among other things, how the UE should behave w.r.t CS fallback depending on the capabilities reported by the network.
2017-12-05docs: include device filter policies/rules documentationAleksander Morgado