On Sat, 2011-10-01 at 15:45 +0200, Aleksander Morgado wrote: > Hey hey, > > > > Supported and Allowed modes are modified to be bitmasks of MM_MODEM_MODE > > > values, > > > and preference of a specific mode is now given in the new PreferredMode > > > property and as an extra argument to the SetAllowedModes() call. > > > > > > * Supported Modes: bitmask specifying which modes are supported by the > > > specific > > > hardware. For example, a modem may only support 1G/2G/3G connections (not > > > 4G). > > > > > > * Allowed Modes: bitmask specifying which modes, of the ones Supported > > > by the > > > modem, are allowed to use. For example, a modem may support 1G/2G/3G > > > connections > > > but only 1G and 2G connections are allowed by the user as 3G involves more > > > expensive data rates. > > > > > > [Allowed] ⊆ [Supported] > > > > > > * Preferred Mode: specific mode which is preferred among the ones > > > defined in > > > the Allowed modes bitmask. For example, a modem may allow 1G/2G/3G > > > connections > > > but the user would like that if possible 2G be used, as 3G consumes too > > > much > > > battery. If 2G is not possible, 3G can be used. > > > > > > [Preferred] ∈ [Allowed] > > > > I don't have a huge objection to this, but I'm not sure I see the > > benefit of having the Preferred/Allowed split versus the complexity. > > Basically, if Allowed were an enum where we enumerated the preference > > there are 4 items to choose from (4G, 3G, 2G, empty) and 3 slots in the > > preference order (since empty doesn't get a slot, just a single enum). > > Thats a total of 25 combinations, but some like 2G>4G don't really make > > sense, so we have somewhere under 25. 32-bits gives us a lot of range > > there if it's an enum not a bitfield. The downside is that it has no > > relationship with the MM_MODEM_MODE flags. My worry is just that it's > > added complexity (3 properties to check instead of 2) that may be just a > > bit more work for clients. > > > > I do see problems in both implementations, and I understand that the new > one may be more complex, but trying to cope with the addition of 4G to > the list is not an easy task, I would say.
Yeah, I know. > It would be good to check what modes the new LTE devices support. Is > there anyone out there who can check this? Do the devices support > specifying 'preferred' modes to automatically connect in one mode or > another? Unfortunately I don't have any information on this, we'd have to ask contacts at Novatel, Sierra, Qualcomm, etc what the plans are here if we can. Qualcomm chips do have the ability to select a different "mode preference", and as far as I can tell from the reverse engineering we've done, it's a gigantic enum for every mode conceivable because they include stuff like WiFi in there too. Think stuff like CDMA/AMPS/HDR/WLAN-only (ie 2G/1G/3G/Wifi only) as a distinct value from HDR/LTE only (ie 3G/4G only). And values for things like "anything except WiFi". So you can bet they've added a bunch more options to that enum for LTE. > Also, do the 4G devices support complex setups like "3G preferred, and > if not available go 4G" or "3G preferred, and if not available go 2G". > As a user, I think I can find good reasons to need these last two > options, not just "3G preferred". Yeah, that's the question... not sure we have an answer yet. But I guess it would be good to be able to do this since we aren't sure. Dan _______________________________________________ networkmanager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
