On Mon, Oct 3, 2011 at 7:34 PM, Dan Williams <d...@redhat.com> wrote:
> 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. > > I am trying to figure out some more details on what the Novatel E362 supports. I'll report back to the list. -Jason > Dan > > _______________________________________________ > networkmanager-list mailing list > networkmanager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list >
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
