Porting/GPS - Revision history

ashley: Reverted edits by 37.7.37.18 (Talk) to last revision by sixwheeledbeast

2021-11-26T10:58:00Z

Reverted edits by 37.7.37.18 (Talk) to last revision by sixwheeledbeast

← Older revision		Revision as of 10:58, 26 November 2021
Line 18:		Line 18:
	[[Category:Neo900]]		[[Category:Neo900]]
	[[Category:GPS]]		[[Category:GPS]]
-	~~[[Media:Example.ogg]]~~
-	~~== Headline text ==~~

37.7.37.18: /* Proposal */

2021-11-22T00:26:21Z

Proposal

← Older revision		Revision as of 00:26, 22 November 2021
Line 18:		Line 18:
	[[Category:Neo900]]		[[Category:Neo900]]
	[[Category:GPS]]		[[Category:GPS]]
		+	[[Media:Example.ogg]]
		+	== Headline text ==

sixwheeledbeast: /* Thoughts on how to handle GPS in Fremantle-port/Neo900 */

2013-09-14T10:15:06Z

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

← Older revision		Revision as of 10:15, 14 September 2013
Line 1:		Line 1:
	= Thoughts on how to handle GPS in Fremantle-port/Neo900 =		= 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)		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:		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)

sixwheeledbeast at 08:00, 14 September 2013

2013-09-14T08:00:09Z

← Older revision		Revision as of 08:00, 14 September 2013
Line 13:		Line 13:
	[[Category:Fremantle]]		[[Category:Fremantle]]
	[[Category:Neo900]]		[[Category:Neo900]]
		+	[[Category:GPS]]

sixwheeledbeast at 07:58, 14 September 2013

2013-09-14T07:58:25Z

← Older revision		Revision as of 07:58, 14 September 2013
Line 9:		Line 9:

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

jonwil: /* Thoughts on how to handle GPS in Fremantle-port/Neo900 */

2013-09-13T16:53:40Z

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

← Older revision		Revision as of 16:53, 13 September 2013
Line 2:		Line 2:
	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)		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)
	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:		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)	+	# 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.	+	# 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.	+	# 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).	+	# 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.	+	# 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.		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.

jonwil: Created page with "= 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 …"

2013-09-13T16:50:27Z

Created page with "= 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 …"

New page

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