| Age | Commit message (Collapse) | Author |
|---|
|
|
|
g_free is in form of `void (*)(gpointer)`, which matches the
GDestroyNotify signature. An explicit GDestroyNotify cast on g_free is
thus not needed.
|
|
|
|
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
|
|
|
|
mm-shared-qmi.c:358:9: error: variable 'mcc' is used uninitialized whenever '&&' condition is false [-Werror,-Wsometimes-uninitialized]
if (operator_id && !mm_3gpp_parse_operator_id (operator_id, &mcc, &mnc, &error)) {
^~~~~~~~~~~
mm-shared-qmi.c:367:9: note: uninitialized use occurs here
if (mcc) {
^~~
mm-shared-qmi.c:358:9: note: remove the '&&' if its condition is always true
if (operator_id && !mm_3gpp_parse_operator_id (operator_id, &mcc, &mnc, &error)) {
^~~~~~~~~~~~~~
mm-shared-qmi.c:339:51: note: initialize the variable 'mcc' to silence this warning
guint16 mcc;
^
= 0
|
|
The modem may take the request to set modes and reply right away with
a success before actually changing the current modes in use.
Therefore, If we reload modes right after we receive the set response,
we may still see the old modes instead of the new ones. Try to avoid
this, by reloading current modes a couple of times after we have set
them if they are not yet the expected ones.
|
|
The modem may take the request to set bands and reply right away with
a success before actually changing the current bands in use.
Therefore, If we reload bands right after we receive the set response,
we may still see the old band mask instead of the new one. Try to
avoid this, by reloading current bands a couple of times after we have
set them if the band mask is not the expected one.
|
|
|
|
These new methods allow querying and updating the status of the call
waiting network service, as per 3GPP TS 22.083.
The status of the service is not a property because we don't want to
unconditionally load it on every boot, given that the process involves
talking to the network (i.e. it is not a device setting).
|
|
Do not wait until all parts are received in order to initialize all
fields that are common to all parts in the SMS message, do it as soon
as the first part is received.
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/137
|
|
The tool monitors SMS message additions and SMS state updates, e.g.:
$ sudo ./test/mmsmsmonitor
[/org/freedesktop/ModemManager1/SMS/0] sms found: received
[/org/freedesktop/ModemManager1/SMS/1] sms found: received
[/org/freedesktop/ModemManager1/SMS/2] sms found: received
[/org/freedesktop/ModemManager1/SMS/3] sms found: received
[/org/freedesktop/ModemManager1/SMS/4] sms found: received
[/org/freedesktop/ModemManager1/SMS/5] sms found: received
[/org/freedesktop/ModemManager1/SMS/6] sms found: received
[/org/freedesktop/ModemManager1/SMS/7] new sms: receiving
[/org/freedesktop/ModemManager1/SMS/7] sms updated: received
|
|
|
|
We were not logging anywhere the "concat max" field for example.
|
|
The QMI NAS Initiate Network Register command will return a successful
response when the request to register is received and accepted by the
module, but this does not mean the requested registration has been
completed yet.
This issue was making e.g. manual registration attempts to a forbidden
network report success right away, even if the actual registration
would end up failing.
In order to avoid that, the QMI based network registration relies on
receiving QMI NAS Serving System indications after QMI NAS Initiate
Network Register replies. As soon as we get a non-searching
registration state in the indication, we'll report the operation as
successful.
Note that the 3GPP interface logic is anyway in charge of checking
if the specific request was successful or not, no need to do that
explicitly in the QMI implementation.
|
|
If there is one registration state which is denied and the remaining
ones are either unknown or idle, then report denied.
|
|
|
|
|
|
|
|
The GSM supplementary services related changes, as well as the rework
done to manage calls per call id, is copyrighted by Purism SPC.
|
|
We will parse +CTZU URCs, which end up getting in the way of other
commands if we don't process them.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/135
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It will be set to TRUE if this call is part of a multiparty call.
|
|
The in-call unsolicited events and the in-call audio settings are
managed exclusively at modem level, and no longer at call object
level. This is because these two things are applicable to all calls
that may be active at the same time.
|
|
The in-call handlers will monitor events that report the call being
terminated.
|
|
The audio channel setup is shared between all ongoing calls, so it is
a modem-level feature, not specific to a single call.
|
|
E.g. if we want the modem-level in-call state management to provide
what audio settings are expected in all ongoing calls.
|
|
The URCs report the specific call index they apply to, so they should
be managed by the modem object and reported to the Voice interface.
|
|
If the URC reporting the DTMF does not specify the call index,
mark it as received in all active ones.
|
|
+UCALLSTAT is used to report the state of specific calls by index, and
therefore this is not an in-call URC.
|
|
Instead of providing a method to exclusively provide incoming call
updates, make it more generic so that we allow plugins to provide
state updates for any kind of call, not just incoming ones.
The logic to match the call info provided by URCs is updated so that
it can be reused also by the single call reports, in addition to the
full call list reports.
|
|
We cannot handle in-call state at call level because the state may
apply to multiple active calls at the same time:
* the modem is in-call if there is at least one ongoing call (>=1).
* the modem is not in-call if there are no ongoing calls (==0).
The new logic implements call state monitoring for all available call
objects, and whenever the state of one or more calls change, we'll go
over all of them to see how many of the calls can be considered to be
ongoing (i.e. not terminated, not unknown). If we have at least one
call ongoing, we'll setup the in-call state and otherwise, we'll clean
it up.
Setting up and cleaning up the in-call state involves unsolicited
message and audio channel settings management operations.
|
|
|
|
|
|
|
|
This method allows deflecting an incoming or waiting call to a
different number.
|
|
|
|
This method will join all active and held calls into a single
multiparty call, and then request the network to terminate the call on
the subscriber's end and transfer the control of the call to the
parties that are still in the call.
|
|
|
|
This method will terminate all ongoing calls.
|
|
|
|
This method will put the currently active call on hold, and right away
accept the next available call.
The user of the API does not need to specify explicitly which is the
next call to accept, because that is decided automatically:
* If there is any waiting call, it will accept it right away.
* If there is no waiting call but there is a held call, it will make
the held call active again.
|
