aboutsummaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2012-03-15sim: allow re-launching initializationAleksander Morgado
It may happen that we cannot load property values when the SIM is locked, so we need to enable re-launching initialization in the object API.
2012-03-15sim: load OperatorName during initAleksander Morgado
2012-03-15sim: load OperatorIdentifier during initAleksander Morgado
2012-03-15sim: load IMSI during initAleksander Morgado
2012-03-15sim: load SIM Identifier during initAleksander Morgado
2012-03-15core: new MMSim object, inherits from MmGdbusSimAleksander Morgado
2012-03-15iface-modem: relaunch init when being unlockedAleksander Morgado
2012-03-15iface-modem: new `State' property, bound to the one in the MmGDbusModem skeletonAleksander Morgado
2012-03-15iface-modem: load `SupportedModes' and `SupportedBands' during initAleksander Morgado
2012-03-15iface-modem: load `UnlockRequired' and `UnlockRetries' during initAleksander Morgado
And also allow being loaded upon user request, with `mm_iface_modem_unlock_check()'.
2012-03-15iface-modem: load `EquipmentIdentifier' and `DeviceIdentifier' during initAleksander Morgado
2012-03-15iface-modem: load `Manufacturer', `Model' and `Revision' during initAleksander Morgado
2012-03-15iface-modem: load `MaxBearers' and `MaxActiveBearers' during initAleksander Morgado
2012-03-15iface-modem: load `ModemCapabilities' and `CurrentCapabilities' during initAleksander Morgado
When the interface gets initialized, start loading modem and current capabilities.
2012-03-15iface-modem: set `Device', `Driver' and `Plugin' during initAleksander Morgado
Values taken from the MMBaseModem object, which are not expected to change during the lifetime of the Modem object.
2012-03-15core: new MMIfaceModem interfaceAleksander Morgado
This interface controls the availability of the DBus Modem interface, and implements the actions that may be performed in the interface.
2012-03-15base-modem: new `enable()' and `disable()' async methodsAleksander Morgado
Users will be able to enable or disable modems using the DBus interface. We will chain up the `Enable(boolean)' call from the DBus interface to these new methods in the base modem class.
2012-03-15base-modem: new virtual initialize() methodAleksander Morgado
Whenever the first AT port is grabbed, we launch the initialize() method, which must have been implemented by the corresponding modem subclass.
2012-03-15base-modem: new property to keep the Connection objectAleksander Morgado
2012-03-15base-modem: new properties for vendor and product IDsAleksander Morgado
These will be set during modem object creation.
2012-03-15base-modem: getters for primary/secondary/qcdm portsAleksander Morgado
2012-03-15base-modem: set v1 serial parser alwaysAleksander Morgado
CDMA modems used to use the v1_e1 serial parser; but we'll try to setup a common one in all modems.
2012-03-15base-modem: new properties to handle Device, Driver and PluginAleksander Morgado
They will be set when constructing the object.
2012-03-15base-modem: ported all port grabbing/releasing logic to the base objectAleksander Morgado
2012-03-15base-modem: expect a GDBusMethodInvocation as context of the auth requestAleksander Morgado
2012-03-15core: new MMBaseModem abstract typeAleksander Morgado
Basically, a replacement of the MMModemBase type, being prepared to handle multimode devices. This object derives from a MmGdbusObjectSkeleton, which makes it suitable to be controlled within the GDBusObjectManagerServer.
2012-03-15core: new AT command and sequence processorsAleksander Morgado
This setup, allows: - Running a single command and processing its result. - Running a set of N commands, providing a global result after all have been executed. - Running a set of N commands out of M (N<M), where the global result is obtained without having executed all configured commands. This is useful when probing, for example.
2012-03-15manager: make it export the Object Manager interfaceAleksander Morgado
2012-03-15manager: let it be initableAleksander Morgado
The MMManager object creation may fail due to environment reasons (i.e. no plugins found, or problems exporting DBus interfaces), so we can use the initable interface to properly handle those situations.
2012-03-15manager: keep the GDBus connection reference in a 'connection' propertyAleksander Morgado
2012-03-15manager: use G_TYPE_INSTANCE_GET_PRIVATE() just to create the private structAleksander Morgado
A new 'priv' pointer is added in the MMManager struct, which will contain the address of the private structure.
2012-03-15core: implement the Manager1 DBus interface, based on GDBusAleksander Morgado
The MMManager object now derives from the gdbus-codegen-generated MmGdbusOrgFreedesktopModemManager1Skeleton object, and implements the handlers for the SetLogging() and ScanDevices() DBus methods. The main program is also modified to be based on GDBus.
2012-03-15plugin-base: properly handle Core errorsAleksander Morgado
2012-03-15plugin-base: clear internally tracked probe if port unsupportedAleksander Morgado
If the port is supported by the plugin, leave the probe in the internal HT until the port gets grabbed afterwards.
2012-03-15manager: clear cached port probe when device is removedAleksander Morgado
2012-03-15plugin-base: remove `MM_PLUGIN_SUPPORTS_PORT_IN_PROGRESS' statusAleksander Morgado
Support checks are fully asynchronous and result is always reported when the check is considered ready, so in-progress replies to `mm_plugin_supports_port_finish()' don't make any sense.
2012-03-15plugin-base: don't report numeric support level in the [0-100] rangeAleksander Morgado
There is no single case where more than one plugin may end up wanting to support a given port, and therefore there is no need to report the numeric support level when reporting SUPPORTED.
2012-03-15plugin-base: avoid trying to probe 'net' devicesAleksander Morgado
Some devices support 'net' devices, which cannot be AT or QCDM probed. If the port being checked for support corresponds to an already existing modem, the port will be reported as SUPPORTED. If this is the first port of the modem being checked for support, we will just DEFER the support check until we get a modem created.
2012-03-15plugin-base: keep a MMPluginSupportsResult in the async resultAleksander Morgado
Instead of just a boolean, provide a MMPluginSupportsResult, so that we can pass it as is during `supports_port_finish()'.
2012-03-15plugin-base: improve the logic to check whether vendor or product probing neededAleksander Morgado
If the plugin does a Vendor ID check and it passes, it doesn't need Vendor string probing. If the plugin does a Vendor ID check and it fails: - If Vendor strings reported, it needs Vendor probing. - If Vendor strings not reported, fail as unsupported. If the plugin does a Product ID check and it passes, it doesn't need Product string probing. If the plugin does a Product ID check and it fails: - If Product strings reported, it needs Product probing. - If Product strings not reported, fail as unsupported.
2012-03-15plugin-base: apply post-probing filteringAleksander Morgado
Once probing is finished, the plugin will check whether the port is supported or not based on the following filters: - Capabilities - Reported Vendor string - Reported Product string
2012-03-15plugin-base: apply pre-probing filteringAleksander Morgado
Before any real probing is launched in the port, the plugin will check whether it can skip the request based on the following filters: - Subsystems - Drivers - udev-reported Vendor ID - udev-reported Product ID - udev-reported Tags
2012-03-15plugin-base: make the plugin base use the new port probing mechanismAleksander Morgado
The previous 'MMPluginBaseSupportsTask' object is more or less equivalent to the new `MMPortProbe' in terms of what information it contains. The main difference being that the new `MMPortProbe' object handles internally the whole probing flow as needed: only the needed probing sequences are done. For example, vendor or product string probing will only be performed if a plugin requests it.
2012-03-15port-probe: properly handle Core errorsAleksander Morgado
Fixes compilation of the Port Probe object.
2012-03-15plugin-base: new 'allowed-udev-tags' propertyAleksander Morgado
The plugins can set this property to filter support check requests by the availability of a given udev tag in the port. The value given to the property should be a NULL-terminated array of C strings, e.g.: const gchar *tags[] = { "ID_MM_X22X_TAGGED", NULL };
2012-03-15plugin-base: new 'allowed-drivers' propertyAleksander Morgado
The plugins can set this property to filter support check requests by physical device driver. The value given to the property should be a NULL-terminated array of C strings, e.g.: const gchar *drivers[] = { "qcserial", NULL };
2012-03-15plugin-base: new 'allowed-qcdm' propertyAleksander Morgado
The plugins can set this boolean property to specify whether they can handle QCDM ports, and therefore probing for them is needed.
2012-03-15plugin-base: new 'send-delay' propertyAleksander Morgado
The plugins can set this property to provide a custom value for the send delay used for characters sent to the AT port during probing. The value given to the property should be a guint64 specifying the delay in microseconds.
2012-03-15plugin-base: new 'allowed-capabilities' propertyAleksander Morgado
The plugins can set this property to filter support check requests by probed capabilities. The value given to the property should be a guint built as a mask of MM_PORT_PROBE_CAPABILITY flags, e.g.: const guint capabilities = (MM_PORT_PROBE_CAPABILITY_GSM | MM_PORT_PROBE_CAPABILITY_CDMA);
2012-03-15plugin-base: new 'allowed-vendor-strings' and 'allowed-product-strings' ↵Aleksander Morgado
properties The plugins can set these properties to filter support check requests by AT-reported Vendor string and Product string. The value given to the properties should be a NULL-terminated array of strings, e.g., static const gchar *vendor_strings[] = { "cinterion" , NULL };