On Wed, 2011-10-05 at 13:51 -0400, Jason Glasgow wrote:
>
>
> On Mon, Oct 3, 2011 at 7:34 PM, Dan Williams <
dcbw 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.
