On Wed, Mar 03, 2010 at 04:32:51PM +0000, Neil Jerram wrote: > On 3 March 2010 16:08, Martin Jansa <martin.ja...@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.ja...@gmail.com Jansa Martin sip:jama...@voip.wengo.fr JaMa _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community