| Age | Commit message (Collapse) | Author |
|---|
|
Apparently g_convert() can still return garbage that's not valid in
the character set you're converting to (???). But even if we don't
need to convert the operator name, make sure it's valid UTF-8 before
we go shoving it through D-Bus.
|
|
Need to emit the D-Bus API property name, not the GObject property
name for a few things on the Location interface.
|
|
|
|
Depends on dbus-glib 0.86 + this patch:
https://bugs.freedesktop.org/show_bug.cgi?id=28835
Still have to do the bits that allow plugins to add other
location capabilities, but that can come later.
|
|
|
|
|
|
Cleanups and authorization checks by me (dcbw).
|
|
|
|
Returns the ID of the operator that issued the SIM card.
Cleanups and get_mnc_length_done() by me (dcbw).
|
|
|
|
|
|
Which reports the # of attempts remaining for the current PIN required
by the device or SIM.
Some modifications/cleanups by dcbw.
|
|
Found by jklimes. If some plugin already supports this port, it's
pointless to let Generic figure out if it supports the port since
we're just going to hand it to the other plugin anyway.
|
|
|
|
Prevents crashes when the callback info completes when the modem is
removed, plus it's the right thing to do anyway...
|
|
Some devices (Blackberries) always respond to AT+CREG with ERROR,
but will respond to AT+CGREG normally. Ugh. Handle that by
using the PS registration status from AT+CGREG if we don't have
a valid CS registration status at all.
|
|
The flash function could be called when the port was closed, and since
the flash function would only be canceled when the port was open,
it could trigger after the port object was destroyed.
|
|
|
|
|
|
|
|
Distributions should set dist-version at build time with the
package version and revision, so for RPM-based distros you'd
--with-dist-version=%{version}-%{release}
which will be printed out on MM startup to help debugging.
|
|
|
|
|
|
See also d5ca82eade4c341a18a72e6f16c9db4ee34be4d5
|
|
Since MMModem is an interface and doesn't store stuff like the
modem's physdev internally (since it's an interface) these things
are handled via GObject properties. And since g_object_get()
returns allocated values, we need to free the returned value
from mm_modem_get_device() after we're done with it.
|
|
|
|
There are some cases where flashing the primary port doesn't work
either due to stupid modem firmware or crappy kernel drivers. So
if we have a secondary port, try sending the PDP deactivation
command to the secondary port first, and if that fails send it
to the primary port after the primary port gets flashed. This
increases the chances that the +CGACT request will be successful.
Some modems (Huawei, ZTE) don't like +CGACT on the secondary port,
but when that fails, the code falls back to previous behavior of
flashing and sending CGACT to the primary port.
|
|
Some phones like the T630 don't put a space after the ':'.
|
|
The argument passed to the handler is a GByteArray, not a
GString. Encountered with Option iCON Icera-based devices,
but could also be possible with Sierra devices.
|
|
|
|
QCDM ports should never be the data port; 'net' ports take precedence
over AT ports too. Clarify that.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Not all devices support unsolicited responses for access technology,
so lets poll it periodically along with registration state and
signal quality.
|
|
This specifically fixes a regression with Novatel GSM secondary
AT port enablement, where the inital pin check closed the port
before the Novatel plugin could send the command to flip secondary
ports to AT mode.
But it's useful elsewhere too, and simplifies a bunch of the PIN
checking code which had to use various ugly methods to track whether
to close the port or not after checking the PIN.
|
|
Some devices (Blackberries via DUN) appear to always return an error
for AT+CREG, which is valid in some cases. If that happens lets also
try AT+CGREG too, which on these devices responds with the correct
packet data registration state.
|
|
|
|
|
|
Should have ERROR in them.
|
|
|
|
|
|
|
|
|
|
|
|
The master device of PCMCIA-provided ports is typically the
last device in the PCMCIA subsystem, because the PCMCIA
controller is usually a PCI device or some other subsystem.
|
|
#613490)
Some devices (ZTE MF110 for example) respond immediately to the unlock
request, but in reality take a bit of time before they are actually
unlocked. Check PIN status a few times after sending the unlock.
|
