aboutsummaryrefslogtreecommitdiff
path: root/plugins/mm-plugin-generic.c
AgeCommit message (Collapse)Author
2012-03-15plugins: always set a proper error domain in GErrorsAleksander Morgado
2012-03-15generic: allow QCDM portsAleksander Morgado
2012-03-15core: start using our newly defined errorsAleksander Morgado
2012-03-15core: start using MMBroadbandModem objectsAleksander Morgado
We chain up the Generic plugin created MMBroadbandModem objects within the GDBusObjectManagerServer in MMManager, so that they get properly exported in DBus.
2012-03-15generic: rewrite the plugin to use the new port probingAleksander Morgado
2012-02-28core: rework port grabbing and organizationDan Williams
Make port roles more flexible. We have modems that do PPP on interfaces other than the primary interface, and that wasn't possible with the old code. So clean up all that logic and move the port organization code into the core so we can reduce code in the plugins. In the new world order, the plugins say whether the port is a QCDM port, an AT port, or ignored. If it's an AT port the plugins get to tag it as primary, secondary, or PPP, or any combination of the 3. This allows for modems where PPP should really be done on the secondary port (Huawei E220, Sierra devices) so that the primary port stays open for command and status. Modem subclasses no longer get asked to handle port grabbing themselves. Instead, that's now done by the generic classes (MMGenericCdma and MMGenericGsm) and the plugins are notified when a port is grabbed so they can add unsolicited response handlers for it. After all ports are grabbed by the generic classes, they get "organized", which assigns various ports to the roles of PRIMARY, SECONDARY, DATA, and QCDM based on specific rules and hints that the plugin provided (which are expressed as MMAtPortFlags). The plugins then have a chance to perform fixups on the primary port if they choose. The plugin code is responsible for determining the port hints (ie MMAtPortFlags) at probe time, instead of having a combination of the plugin and the modem class do the job. This simplifies things greatly for the plugins at the expense of more complicated logic in the core.
2011-06-06plugins: propagate cached probing result to supports taskAleksander Morgado
We need to ensure that the supports task always has the results of the probing, no matter if the probing was just launched by the plugin grabbing the port, or by a previous plugin. We do this during supports_port(), by propagating to the supports task any possible previously cached probing results.
2011-04-08serial: allow plugins to specify probe-time send_delayDan Williams
Let modems we know don't suck use a zero send-delay at probe time, which greatly reduces time required to probe AT-compatible ports.
2011-01-23core: rework loggingDan Williams
Make it more flexible, add logging to a file, and absolute and relative timestamps.
2010-10-22core: use hardware IDs as part of DeviceIdentifierDan Williams
Pass the device's hardware IDs through modem creation and use them when calculating the device's identifier. Add a bunch of testcases for real hardware to ensure we don't break the device ID in the future unless we really want to.
2010-09-21core: prefer CDMA capabilities over GSM for dual-mode devices (bgo #621815)Dan Williams
For devices like the UMW190 that appear to be dual-mode without needing a firmware reload (unlike Gobis, which are dual-mode but require a reboot with different firwmare) prefer CDMA capabilities since that's where these devices will most likely be used more often. In the end we'll need to change MM to advertise a "capabilities" attribute on the modem class and modify devices such that they can implement both GSM and CDMA semantics at the same time.
2010-03-30core: move physical device checking into the managerDan Williams
It turns out that the manager needs to know about the physical device so we can prevent multiple plugins from claiming ports on the same modem.
2010-03-23core: grab probed QCDM ports for plugins where they are usefulDan Williams
2009-10-12cdma: split 1x and EVDO registration statesDan Williams
Like UMTS vs. GSM, EVDO and 1x are separate networks and technologies and have separate registration state. You can even be roaming on EVDO while in your home 1x network. Handle that.
2009-10-02bluetooth: recognize rfcomm devicesDan Williams
Two hacks here: 1) rfcomm ports don't have an easily accessible driver name, so we just match the parent's subsystem to 'bluetooth' and use that 2) libgudev doesn't seem be be able to get the rfcomm device's device file, which would normally be /dev/rfcommX. Oh well, we don't use the device file yet anyway
2009-07-02plugins: allow plugins to more easily suggest port typesDan Williams
ZTE modems need to use udev rules to assign port type hints, so generalize that and port all the plugins over to suggested port types in the MMModem interface's grab_port() function.
2009-06-29generic: remove unused codeDan Williams
2009-06-28asynchronous and deferred port detectionDan Williams
Allow plugins to perform asynchronous port detection, and to defer port detection until later. This moves the prober bits into MMPluginBase so that all plugins can take adavantage of it only when needed; the probing is not done at udev time. Furthermore, plugins like Novatel can flip the secondary ports over the AT mode through deferred detection, by deferring the secondary ports until the main port has been detected and AT$NWDMAT has been sent. This commit also finishes the port of the rest of the plugins (except mbm) over to the new port detection methods and plugin API.
2009-06-19plugin: add a base class to handle modem trackingDan Williams
2009-06-18generic: misc fixesDan Williams
2009-06-18udev: move device probing and detection to udevDan Williams
Get rid of dependency on HAL, using libgudev instead. Fix up the plugin API to no longer use either HAL or udev defines, but let plugins use whatever mechanism they want for getting more information out of the device given the subsystem and device node name. Modems are now defined as "master" devices which "own" a one or more ports. A port could be a serial tty device or a network device or whatever. The plugin figures out whether it supports a given port or not and then assigns it to a new or existing modem. Modems now have a 'valid' property that should be set to TRUE when the modem has enough ports to operate correctly. For devices (ex. 'hso') that use a network device for data transfer, the modem would need to grab at least one TTY and the network device associated with that physical device to be 'valid'. Also move the generic modem support code to a plugin like other modem plugins, and change the I-support-this-device mechanism to return a number indicating the level of support. For example, the generic plugin would return a quite low number if the device indicates via probing that it can do GSM or CDMA, but a more specific plugin can indicate better support for the device, and thus the more specific plugin would win control.