When an outgoing call is created and added to the call list its state
is UNKNOWN. The call list emits the ADDED signal which MMIfaceModemVoice
listens for to check whether to begin polling call state.
But since UNKNOWN is not an in-progress call state polling isn't started.
And nothing was rechecking whether to start polling when the call state
changed to something other than UNKNOWN.
Do that so that we can track call progress as it dials out and is
answered.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
(cherry picked from commit 92e666e1c9)
Missing ! for strncmp() meant the test was backwards and would
erroneously report 1xRTT and EVDOr0 when those access technologies
were not in use.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
(cherry picked from commit 9e205f4784)
Fix a duplicate `id` and the inclusions of gdbus docs.
Signed-off-by: Jan Alexander Steffens (heftig) <heftig@archlinux.org>
(cherry picked from commit 078a92cd5c)
We want ports to be closed as early as possible; so make sure they
are closed in dispose() which is run explicitly by MMDevice when
cleaning up and removing the modem. Otherwise they could stay
open longer than we want, causing problems for suspend/resume.
This caused problems with suspend because cancelling the
MMBaseModem's cancellable triggered an idle handler that held
a reference to the modem, preventing finalize() from running
until after the suspend code was finished, thus preventing
ports from being closed and cleaned up. Closing them in
dispose() handles this.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
base_modem_invalid_idle() needs to keep a reference to the
MMBaseModem until its done. But if the modem is cancelled during
removal right before we're trying to forget about it, keeping
that reference can prevent everything getting cleaned up by
MMBaseModem's dispose() until after the mainloop has run again
and all our removal operations are supposedly complete.
MMDevice uses an explicit dispose() trigger that mitigates
most of this (and requires it for other reasons, like breaking
reference cycles between the modem and it's various child
classes) but it's somewhat error-prone to keep the modem
around if we don't really need to.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Every use of mm_device_remove_modem() was already trying to cancel the
modem's canellable, so let's just put it there and simplify the callers.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Dell Snapdragon X62 before FCC Unlock reports no radio interfaces
from QMI and no device capabilities from MBIM. Instead of asserting
in mm_filter_supported_modes() when called from
mm_supported_modes_from_qmi_supported_modes_context() gracefully
handle the lack of supported modes.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
The script was combining all commit messages into one due to the quoting
of "${COMMIT}", rather than leaving unquoted and picking each individual
commit from the space separated string.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
MBIM modems report RSSI and sometimes don't report more detailed RSRP
and SNR info their MBIMex v2 signal-state replies. RSSI gets reported
for every other access technology, and while it's not as good a signal
indicator as the others, we might as well show something.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Consistently interpret the modem's reported custom data class when
loading current mode, supported mode, supported capabilities,
setting current mode, and current access technology.
Normalize the data class to include any custom data class immediately
after reading it from any MBIM message. De-normalize it when sending
back to the modem when setting current modes so the modem receives
MBIM_DATA_CLASS_CUSTOM for the custom mode.
Fixes: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/937
Signed-off-by: Dan Williams <dan@ioncontrol.co>
This enables the usage with busybox and strict environments.
This is related to #483 and the previous commit 91ed72aa, 02baf283.
Signed-off-by: Jongmin Kim <jmkim@debian.org>
`CSCB` has the form
```
CSCB: [0|1],"<channel-list>","<data-coding-scheme>"
```
If the first parameter is `0` this specifies the accepted types if `1`
it specifies rejected.
So far seen in the wild were CSCB strings with accepted types only and a
coding scheme of "" so this is what we handle for the moment.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
Dan Williams
Jan Alexander Steffens (heftig)
Guido Günther
Jongmin Kim