Hi, On Fri, May 04, 2018 at 10:03:15PM +0200, Pavel Machek wrote: > > > Finally, note that documentation (including kerneldoc) remains to be > > > written, but hopefully this will not hinder review given that the > > > current interfaces are fairly self-describing. > > > > Great work. I like your design decisions. I have quite a few devices > > with have non-serial based GPS peripherals using binary protocols (*). > > As far as I can see it should be possible to add support for those. > > > > I have one concern, though. While providing raw data by > > default is fine generally, it is a problem with device > > auto-discovery. I think there should be some IOCTL from > > the start, that can be used to inform userspace about > > the raw protocol being used (i.e. "NMEA"). I fear, that > > userspace may start to just assume raw = NMEA without > > having this (especially since all initial drivers provide > > NMEA). > > Yep, that would be nice. > > > (*) I have those in mind: > > > > Nokia N900: The phone has GPS integrated into the modem and uses > > ISI encapsulated data. The protocol has been reverse engineered > > and it should be possible to write a kernel driver for handling > > the GPS packets and dumping the raw data to /dev/gnss0. I don't > > think this is particularly useful without a non-raw interface, > > though. It would still require a custom userspace implementation. > > Actually... in this case it would be nice to do the protocol > processing in kernel and just present reasonable interface to > userland... or maybe NMEA. Converting a binary protocol to NMEA, which needs to be string parsed is not very nice. I think first step would be to write a simple driver, which exposes the binary location protocol without ISI header. Then in a second step we can think about a reasonable interface, that should be supported by all GNSS devices. > > Droid 4: GPS is similar to N900, but different protocol and QMI > > encapsulated. This one also has known protocol with userspace > > implementation. I did not yet have a detailed look, if its possible > > to (un)wrap this in the kernel. > > So, this is actually NMEA over QMI. I do have patches libqmi that > provides NMEA on stdout. Ok. So raw data is NMEA for this one. Should be reasonably easy to write a driver exposing this via /dev/gnss device. > But there seems to be another possibile interface (yes, that modem is > crazy, and you can talk to it over few different interfaces), and > that's NMEA over GSM07.10. That one should be feasible to decode in > kernel and just provide NMEA to userland. I think both should be feasible. I suggest to wait a bit more until you and Tony figured out some more details. You've got the libqmi patch as workaround for now and we want a stable API later. -- Sebastian
Attachment:
signature.asc
Description: PGP signature
