Editing Porting/GPS

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

= 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)

== 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.

[[Category:Porting]]
[[Category:Fremantle]]
[[Category:Neo900]]
[[Category:GPS]]

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Retrieved from "http://wiki.maemo.org/Porting/GPS"

Personal tools

Navigation

Views

Editing Porting/GPS

@@ Line 6: / Line 6: @@
 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:
-# 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)
+. 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)
-# 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.
+. 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.
-# 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.
+. 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.
-# 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).
+. 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).
-# 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.
+. 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.