| Age | Commit message (Collapse) | Author |
|---|
|
https://bugzilla.gnome.org/show_bug.cgi?id=712276
|
|
We don't have a Completed signal.
|
|
Will be used in 3GPP2 SMS messages.
|
|
Will be used in 3GPP2 SMS messages.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We will expose a new 'Ports' property listing all ports currently known by a
given modem. Ports which are not used but are detected as being part of the
modem will be listed with an 'unknown' port type.
This change uses the new 'MMModemPortType' enum and the new 'MMModemPortInfo'
helper struct to handle these values in libmm-glib. The already available
'MMPortType' enum hasn't been re-used for the interface because it contains
values that we don't need (e.g. IGNORED).
The port list is now also included in the modem information command of mmcli:
$ sudo mmcli -m 0
/org/freedesktop/ModemManager1/Modem/0 (device id '97b7b99e3e2bea103880545b619fb05a3cc81b26')
-------------------------
System | device: '/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4'
| drivers: 'qcserial, qmi_wwan'
| plugin: 'Gobi'
| primary port: 'cdc-wdm0'
| ports: 'ttyUSB0 (qcdm), ttyUSB1 (at), cdc-wdm0 (qmi), wwp0s29u1u4 (net)'
https://bugzilla.gnome.org/show_bug.cgi?id=702678
|
|
There is no implementation of the Contacts interface yet, just avoid exposing it
for now.
https://bugzilla.gnome.org/show_bug.cgi?id=701989
|
|
|
|
We won't allow changing modes or bands through Simple.Connect(). Applications
should instead look at the corresponding SupportedBands or SupportedModes, and
then use SetCurrentBands() or SetCurrentModes() explicitly.
|
|
For those modems which expose a valid 'SupportedCapabilities' property with more
than one item in the list, we'll allow switching between them.
|
|
And also make it a list of masks, specifying which are the specific combinations
supported, not just one mask with all.
E.g.:
-------------------------
Hardware | manufacturer: 'Sierra Wireless, Incorporated'
| model: 'MC7710'
| revision: 'SWI9200X_03.05.19.04ap r5475 carmd-en-10527 2012/09/17 17:57:14'
| supported: 'gsm-umts
| gsm-umts, lte'
| current: 'gsm-umts, lte'
| equipment id: '358178040668164'
|
|
We now have a single 'CurrentModes' property which contains both values in a
tuple with signature "(uu)".
Also, rename 'SetAllowedModes()' to 'SetCurrentModes()', and update the list of
arguments expected to have a single "(uu)" tuple.
|
|
Instead of just a mask of MMModemMode values, we now provide a list of the
allowed and preferred mode combinations supported by the modem. E.g.:
$> sudo mmcli -m 0
-------------------------
Modes | supported: 'allowed: 2g; preferred: none
| allowed: 3g; preferred: none
| allowed: 2g, 3g; preferred: none
| allowed: 2g, 3g; preferred: 2g
| allowed: 2g, 3g; preferred: 3g
| allowed: 4g; preferred: none
| allowed: 2g, 3g, 4g; preferred: none'
|
|
... and 'SetBands()' to 'SetCurrentBands()'.
We'll keep the 'Current' keyword in those properties which also have
'Supported' values.
|
|
This property will let the clients know which are the IP families supported by
the modem.
|
|
We need to redefine the message class property to int since class
0 is a valid message class. Thus -1 now means "unspecified class".
|
|
#697372)
The GetNetworkTime() response is defined to be an ISO8601 string, which
is in turn defined to be in local time. Make sure that's reflected in
the documentation, and append the timezone offset to UTC where we have
it.
Oddly, Icera devices return their time info in UTC with an offset to
the local timezone, so we have to jump through some hoops there to
convert the response to localtime based on the reported offset.
Some additional fixes by Aleksander Morgado <aleksander@lanedo.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=697372
|
|
We don't want to support only 'relative' validity, so don't assume that the
Validity property will always be a uint32 value.
Instead, we define the Validity propery as '(uv)' tuple, where the first value
(a MMSmsValidityType) specifies the type of validity, and the second value is
a variant formatted accordingly to what the validity type specifies (e.g. a
uint32 value if the type is MM_SMS_VALIDITY_TYPE_RELATIVE).
|
|
|
|
|
|
We currently implement 'SIM missing' and 'SIM error', which are probably the
most common ones.
|
|
Going into/outof low-power state is now a user-requested action.
|
|
|
|
We do need to specify which is the primary port being used for controlling the
modem. This allows us to match the device with an already existing bluetooth
device in NetworkManager.
|
|
For bearers using STATIC or DHCP IP method, the modem itself is the one
negotiating authentication with the network. The new `allowed-auth' property
allows users to specify which authentication method(s) are allowed to be used.
See the following NetworkManager commit for more reference:
commit 34aef8aaaa09b7473b9496aa49e550bd2def03f8
Author: Andrew Bird <ajb@spheresystems.co.uk>
Date: Thu Mar 15 16:19:43 2012 -0500
|
|
|
|
|
|
Also, make only the 'unique-id' mandatory.
|
|
The Firmware interface was highly based on 'slots' to identify the existing
firmware images; but that doesn't fit very well with the initial implementation
of the Firmware interface in QMI-based modems. In these modems the 'storage
index' is a property which is not available in all types of images (e.g. 'PRI'
images don't have it).
Therefore, instead of using a unique 'slot' identifier we'll just use the
'name' of the firmware as unique ID.
Also, currently skip the handling of 'available' images, and the method to
'Install()' new images, at least until we have one implementation defining what
to do with those.
|
|
Image types of `MM_FIRMWARE_IMAGE_TYPE_GENERIC' will expose only the mandatory
parameters. Other vendor-specific images may expose other properties.
|
|
When receiving an SMS, if the encoding is either GSM7 or UCS2, we will treat the
contents of the SMS as text; and if the encoding is either 8BIT or unknown, we
will just dump the contents of the SMS as data.
When creating an SMS, the user is not allowed to give both text and data, only
one can be given. We will use by default 8BIT when data is given, and guess the
best encoding if text is given.
Note that it's still possible to have SMS with neither text nor data, as in
delivery status reports.
This commit also handles the split of the input data in order to make it fit
into singlepart or multipart messages.
|
|
Given only for STATUS REPORT SMS messages.
|
|
We don't support yet modifying these properties on the fly (e.g. we would need
to re-construct the internal PDU list when the text changes).
|
|
Message reference allows to match a sent SMS with its corresponding delivery
report, if requested.
|
|
|
|
It will help deciding the type of message.
|
|
Also allowing the 'delivery-report-request' key in the `Messaging.CreateSms()'
method.
|
|
There is no point in specifying a default 'mem1' memory storage, which is used
for reading/listing/deleting, as those are operations that need a specific
'mem1' set each time.
Also, there is no point in specifying separate default 'mem2' and 'mem3' memory
storages, specially because now we allow Sms.Store() to specify a storage.
So, we will now only have a 'default' memory storage, which is applicable for
both 'mem2' and 'mem3' (storing, sending from storage and deleting).
|
|
We will list which are the storages allowed to use when receiving/storing SMS
messages.
|
|
... or MM_SMS_STORAGE_UNKNOWN to store it in the default storage.
|
|
This signal is no longer needed, as the individual state changes of the SMS
objects are enough to know their correct status of completion.
See https://bugzilla.gnome.org/show_bug.cgi?id=675178
|
|
|
|
We need to expose the raw data for the case where we get SMS messages with
binary content (e.g. settings SMS).
|
