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.
When the serial port buffer gets full of non-AT garbage during port probing,
we were re-scheduling the next probing step, which is completely wrong, as we
then would be processing the same probing task twice. If we get a buffer full,
just cancel the AT probing cancellable, which would cancel not only the possible
AT probings, but also the custom init if there is any.
Also, make sure that the custom_init() of the plugins out there don't return an
error if the GCancellable is cancelled. Cancelling the GCancellable means we
should just stop the custom_init(), and actually sending an error in
custom_init() means that the port should be set as unsupported by the plugin, so
completely different things.
Should fix https://bugzilla.gnome.org/show_bug.cgi?id=696695
If the rules to tag specific USB interface numbers only apply on the PID, we'll
end up seeing that if the port has a parent with another PID, and that other
PID also has a rule, port will get tagged multiple times. Easier to see with an
example:
The ZTE MF637 (VID 0x19D2, PID 0x0121) had the following rules:
ATTRS{idProduct}=="0121", ENV{.MM_USBIFNUM}=="04", ENV{ID_MM_ZTE_PORT_TYPE_MODEM}="1"
ATTRS{idProduct}=="0121", ENV{.MM_USBIFNUM}=="01", ENV{ID_MM_ZTE_PORT_TYPE_AUX}="1"
In our ZTE rules we also have some for the device with PID 0x0002, like:
ATTRS{idProduct}=="0002", ENV{.MM_USBIFNUM}=="02", ENV{ID_MM_ZTE_PORT_TYPE_MODEM}="1"
ATTRS{idProduct}=="0002", ENV{.MM_USBIFNUM}=="04", ENV{ID_MM_ZTE_PORT_TYPE_AUX}="1"
And it seems that we can grab multiple PIDs from a single port, i.e. from the
parent objects in the hierarchy:
udevadm info -a -n /dev/ttyUSB4 | grep idProduct
ATTRS{idProduct}=="0121"
ATTRS{idProduct}=="0020"
ATTRS{idProduct}=="0002"
Where that 0x0002 idProduct is not from the modem, but from the EHCI Host
Controller (with idVendor 0x1d6b in my case).
So... we end up seeing that both set of rules will apply to the ports, and we
misleadingly get:
(ttyUSB3) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2
ZTE: AT port 'tty/ttyUSB2' flagged as primary
(ttyUSB2) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2
ZTE: AT port 'tty/ttyUSB1' flagged as secondary
(ttyUSB1) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2
ZTE: AT port 'tty/ttyUSB4' flagged as primary
b_port(): (ttyUSB4) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2
(/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB2 at (primary)
(/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB1 at (secondary)
(/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB2 data (primary)
(/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB0 qcdm
Which is wrong, as ttyUSB4 should have been our primary port, not ttyUSB2.
With this patch on, the rules apply only to the VID/PID pair, and we end up
getting what we really wanted:
(ttyUSB3) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2
(ttyUSB2) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2
ZTE: AT port 'tty/ttyUSB1' flagged as secondary
(ttyUSB1) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2
ZTE: AT port 'tty/ttyUSB4' flagged as primary
b_port(): (ttyUSB4) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2
(/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB4 at (primary)
(/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB1 at (secondary)
(/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB4 data (primary)
(/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2) tty/ttyUSB0 qcdm
https://bugzilla.gnome.org/show_bug.cgi?id=694759
When setting allowed modes, a ",2" crept into the MODODR command when
porting the plugin from 0.6. That shouldn't be there.
When getting allowed modes, 2 is UMTS preferred and 4 is GSM preferred,
which the previous code combined into only UMTS preferred.
We will not report 'CS' as a supported mode every time '2G' is supported. This
actually was forcing all plugins to handle a 'CS' fallback when they didn't have
CS-specific mode setup. So, to simplify things, we will only report 'CS' as
supported for those plugins which actually allow to select 'CS' mode (e.g. the
'wavecom' plugin).
Both the ModemManager daemon and the mmcli will now include `libmm-glib.h' only.
We also handle two new special `_LIBMM_INSIDE_MM' and `LIBMM_INSIDE_MMCLI'
symbols, which if included before the `libmm-glib.h' library allow us to:
* Don't include the libmm-glib high level API in the ModemManager daemon, as
the object names would clash with those in the core.
* Define some of the methods of helper objects to be included only if compiling
ModemManager daemon or the mmcli.
Different ports of the same modem may get handled by different drivers. We
therefore need to provide a list of drivers (new `Modem.Drivers' property with
signature 'as') instead of just one (removed `Modem.Driver' property with
signature 's').
$ sudo mmcli -m 0 | grep drivers
| drivers: 'qcserial, qmi_wwan'
