Instead of trying to stuff everything into the mode bitfield it
turns out it's just easier, clearer, and simpler to use different
values for each of the following:
1) the device's supported access technologies and allowed modes
2) the device's current access technology
3) the device's allowed mode preference
Since none of the AccessTechnology or AllowedMode stuff has hit a
release yet, let's make sure we're doing it the right way early on.
It's just easier this way. It makes little sense to allow
selecting mode combinations for anything other than
(HSDPA | HSUPA). Most radios don't allow fine-grained control
of the different technologies within each 2G or 3G class anyway
thus combinations like (GPRS | UMTS) are pointless since the
device wouldn't be able to use GPRS but not use EDGE.
This adds split properties and functions for the allowed modes and the
current access technology used by the device when connected to the
mobile network.
MM hadn't implemented it yet, but Wader already implemented an earlier
version that didn't use a bitfield but an enum. Unfortunately the
network mode stuff doesn't allow for distinguishing between the device's
mode preference and the current access technology. So deprecate the
current network mode stuff in the API in preparation for improved API.
Since D-Bus signals cannot by nature be restricted to authenticated
clients (unless using private D-Bus connections) we can handle the
security a bit differently here. Since the Enable() call can be
authenticated, we'll trust the client to say whether higher
security should be used by disallowing location update signals. This
does mean the client will have to poll for location updates, but at
least then clients requesting location information can be
authenticated.
Clients can check the property to determine lock/unlock status and thus
unlock the modem before trying to connect if required.
Bits of the patch by dcbw (see the bug).
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.
Previously, a few operations (like disable) could trigger a modem
flash in parallel with another flash. That's wrong, don't allow
that. At the same time, add in finer-grained error checking on
serial port speed operations, and fix a GSM generic bug that would
send the POWER_UP string on disable.
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.
* Add IpMethod property with known values ppp (default), static, DHCP.
* Rename DataDevice property to Device.
* Add GetIP4Config method. It should be implemented only when IpMethod==static.
* Update org.freedesktop.ModemManager.Modem.Gsm.Sms interface based on
Pablo Martí Gamboa's suggestions.
* Adjust MBM and HSO interfaces to take advantage of the generic Modem
interface.
