• Intro
• Downloads
• Community
• Development
• News
• TALK

Porting/GPS

Latest revision as of 10:58, 26 November 2021

[edit] Thoughts on how to handle GPS in Fremantle-port/Neo900

The GPS architecture on the N900 consists of a low-level library (liblas) that talks to the cellular modem and GPS via libisi and ISI packets, a daemon (location-daemon) that talks to liblas and handles GPS, a daemon (location-proxy) that handles talking to the SUPL server and a library (liblocation) that talks to location-daemon and location-proxy over dbus (and may do other things too)

[edit] Proposal

The proposal I have for porting the GPS stack to new hardware (i.e. anything that doesn't have the same GPS hardware/setup as the N900 does) is as follows:

1. We take liblas, location-daemon, location-proxy, liblocation and any other parts of the GPS system that I forget to mention above and identify anything they do that talks to the outside world (e.g. do they talk to anything via dbus, do they access/set gconf keys, do they read/write/access disk files, whatever)
2. We take the results of that and then identify anything from that list that is used by something that is NOT a part of the GPS stack.
3. We create a library that is 100% compatible (functionally and interface wise) with liblocation on the outside but which talks to whatever new GPS stack we have on the new hardware on the inside.
4. For anything that is talking to the GPS stack directly rather than talking to liblocation, we either clone those items and modify them to talk to the new GPS stack or we create a dummy that exposes the needed interfaces (e.g. dbus interfaces).
5. Then, like magic, all the apps that use GPS (including the microb GPS plugin, nokia-maps and all the 3rd party stuff) should be able to work just fine on the new hardware.

The other option is to go lower level, keep liblocation as-is but create new systems that talk the same dbus interfaces as location-daemon and location-proxy.