MC Navi released
Martin Jansa
martin.jansa at gmail.com
Wed Mar 3 18:08:56 CET 2010
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
More information about the community
mailing list