MC Navi released

[Martin Jansa]

On Wed, Mar 03, 2010 at 04:32:51PM +0000, Neil Jerram wrote:
> On 3 March 2010 16:08, Martin Jansa <martin.jansa at gmail.com> wrote:
> 
> > Or some already existing patch for compatibility with gpsd-2.90?
> 
> That's an interesting question.  Are you considering gpsd for SHR,
> instead of ogpsd + fso-gpsd?

AFAIK gpsd was always built in SHR at least as gpsd.h provider etc. And it was
updated to 2.90 about a week ago. On device there is fso-gpsd and then libgps
now version libgps19 (2.90-r4.0.4).

I'm not really planing any gps switch, but the plan is to remove frameworkd
and python from SHR images ASAP.

1) fsogsmd should work already
2) opimd is redesigned still in python, then it will need vala? rewrite :/
3) fso-gsm depends on frameworkd (ogpsd) now and needs to be replaced/improved
   somehow, that's why I asked mickey
4) I'm building experimental images[1] with 2.6.32 kernel, fsogpsd, xserver-1.8 and 
   without udev, hal, python, frameworkd for myself (they are not usable out of
   the box, but I want to test and prepare SHR for next step :))

12:36.41	JaMa	mickey|office: yes there any plan to make fso_gpsd independent on frameworkd? now it's in RDEPENDS
13:50.33	mickey|office	JaMa: fso-gpsd has not been written by us, the author is somewhat missing in action; i do not have any plans for it. fso-gpsd translates gypsy into gpsd protocol. fsotdld will not use gypsy protocol, so fso-gpsd won't work anyways w/ fso2
13:55.29	JaMa	mickey|office: so fsotdld will provide NMEA? and if we need gpsd protocol provided by fso-gpsd (ie for using gpsd from FR on other device over wifi connection) then someone need to implement NMEA->GPSD right?
13:56.05	mickey|office	JaMa: I'm afraid fsotdld will not provide NMEA, that would not make sense, fsotdld is about giving a high level location protocol
13:56.14	mickey|office	we will have to have something like fsotdld->gpsd, yes
13:56.28	pabs3	how does fsotdld relate to geoclue?
13:56.29	mickey|office	fsotdld will basically incorporate all location providers
13:56.53	mickey|office	pabs3: it looks like there will be an overlap
13:57.20	JaMa	mickey|office: ah so "UBX NEMA" is name of protocol we get from our chip?
13:57.34	mickey|office	JaMa: UBX5 or NMEA, yes
13:57.38	mickey|office	or UBX4
13:57.41	mickey|office	dunno offhand
13:58.07	JaMa	mickey|office: ok thanks
13:58.30	mickey|office	sascha wessel (author of fso-gpsd) once put up a nice RFC of a location provider protocol
13:58.36	mickey|office	i'm leaning towards using that
13:58.43	mickey|office	or make it compatible with geoclue
13:59.01	mickey|office	but last time we made a protocol compatible with something, that something was more or less abandonded ;)
14:00.09	mickey|office	the choice to support gypsy made sense at the time
14:00.14	mickey|office	but the outcome was a horrible protocol
14:00.21	mickey|office	very undbuslike
14:00.30	mickey|office	this time i want to make it better
14:00.52	lindi-	mickey|office: gpsd protocol changed btw
14:01.10	lindi-	mickey|office: support for old protocol will be dropped this year
14:01.28	lindi-	meanwhile it will support both (and autodetect)
14:02.11	lindi-	the one-letter commands are finally gone for good :)
14:03.09	mickey|office	awesome :)
14:03.20	mickey|office	ya, we definitely want a gspd protocol plugin for tdld
14:03.34	JaMa	I'm just reading what mqy (author of omgps said), because he had parsers for all 3 protocols, so maybe it would be easy to convert with help of his code http://lists.openmoko.org/pipermail/community/2009-June/050403.html

[1]: http://gitorious.org/~jama/angstrom/jama-shr-experimental/commits/shr/unstable 
     - don't use this if you don't know what are you doing :) and if you do, expect rebase almost every day

-- 
uin:136542059                jid:Martin.Jansa at gmail.com
Jansa Martin                 sip:jamasip at voip.wengo.fr 
JaMa