Re: [PATCH 8/8] api: Let MM_MODEM_MODE be a bitfield, and new PreferredMode property

Hey Thomas,

> > 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.
> Is it also possible to define the order? eg 1G/2G/3G are available and i
> want to use 1) 2G, 2) 1G and 3) 3G?

This wasn't possible before, and also not possible in this proposal, as
there is only one Preferred Mode given here. If we would like to allow
giving the order of priority to select the modes, as you suggest, we
would need to give a list of mode values instead of just one single

The key point here is what existing modems currently support. It would
be great to allow in the API to specify a given order of modes, but then
the modems should support that, and AFAIK no modem supports specifying
such order. Some modems may allow to force using only 1G or 2G (e.g the
Wavecom I've got, you can force it to setup a slow CS data connection),
without any notion of having one 'preferred' mode; some other modems
allow specifying "2G preferred" or "3G preferred", as we have in the 0.5
API. This proposal doesn't possibly cover all currently existing cases,
but at least I tried to do so.

Of course, if any given combination is not supported by the modem, the
plugins can always return a GError in the SetAllowedModes() call. For
example, modems without any notion of 'preferred' modes could allow only
NONE to be set as Preferred mode.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]