I would be willing to take a shot at an implementation.
Should it be the method with the NMEA device or the QMI interface? (I have 0 experience with the QMI stuff)

Well I would definitely prefer it to be with the QMI LOC service. Take a look at libqmi and the minimal "LOC" service support we currently have there. Also, you may want to ping dcbw as he was working on that as well IIRC.

The modem is currently using the MBIM driver.
It does not have a native QMI device but does support QMI via MBIM).

Should the MBIM driver support location via QMI?

We could als move the logic for these Qualcomm chips into the parent class, as the chipset is used by multiple vendors.
We could then identify the ports via udev rules (different vendors have different identification schemes)

The QMI LOC based gps management could be implemented in a separate common source file, and then used by:
  * the QMI implementation directly (i.e. mm-broadband-modem-qmi.c)
  * the MBIM implementation, if QMI-over-MBIM is supported (i.e. mm-broadband-modem-mbim.c)

That would probably be best, both generic implementations trying to use that service. As for the ports, when using QMI there is no actual need to use the tty to read the GPS NMEA stream! ModemManager can read the GPS info directly using QMI. We still should allow enabling/disabling GPS to be used by external programs via the TTY, and we call this "unmanaged gps", but there wouldn't be any need to "tag" ttys as "gps data port" in MM, as the MM implementation could just use QMI to receive the NMEA stream.

I would begin with unmanaged GPS part.
(So far I could not find any docs about QMI, any pointers are welcome).

About the unmanaged GPS:

Currently the Sierra plugin uses the vanilla QMI and MBIM modem classes without a custom subclass, so there is no usable extension point currently.
To get the logic into the different classes I think there are these choices:

1) Implement new complete new subclasses, only overriding the location stuff. (With all the boilerplate this entails)
2) Monkeypatching the returned object. (No idea if this is possible)
3) Moving the logic into the base modem class.
4) Having some sort of "Mixins". (No idea if this is possible)

Which one do you prefer?

3) Moving the logic into the base modem QMI/MBIM classes; ie mm-broadband-modem-qmi.c and mm-broadband-modem-mbim.c. Just see the GPS support done in the QMI implementation based on the PDS service.

Thanks for the clarification, I somehow thought, that enabling the raw port would be done using the "write magic value to GPS interface" way.

Update:

I sent the groundwork in libqmi to the libqmi-devel list.

I also managed the get the modem into a native QMI mode.
It turned that the QMI-via-MBIM mode would not deliver any QMI indications, making the LOC service unusable there.
(Probably also the PDS service).
Do you know if this is supposed to happen or where the issue could be?
(Normal messages work. Indications are dropped for all tested services)

As at least this modem should be in native QMI mode by default (I managed to change it and forget about it), the LOC-over-QMI-over-MBIM case could be ignored until a modem without native QMI is encountered.

How would you prefer the implementation of the QmiLOC location backend?

*) Both the PDS and LOC implementation living in MMBroadbankModemQmi
*) Dedicated subclasses of MMBroadbandModemQmi for both the PDS and LOC implementations
*) Implementing a new interface MMQmiLocationProvider with subclasses for PDS and LOC
*) Something else I didn't think about (I am quite new to gobject)

Hey! The first option is the most desirable one. If a modem supports LOC, it would use LOC, otherwise we check if the modem supports PDS and if so it would use PDS, and otherwise nothing.

How will we do the unmanaged GPS? I did not find any information about enabling the unmanaged port via QMI/MBIM.

Also the unmanaged GPS implementation would have to be shared between the Sierra, Sierra (legacy), and probably plugins for other modems sharing the Qualcomm chipset.

I fear that we will need a more general sulution to the problems of multiple differently usable location providers.
This could then also be used for the PDS/QMI case.

Personally I am not comfortable with designing this right now, due to missing knowledge about the whole of ModemManager and the capabilities of GObject.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/78.