MC Navi released
neiljerram at googlemail.com
Thu Mar 4 10:40:20 CET 2010
On 3 March 2010 17:08, Martin Jansa <martin.jansa at gmail.com> wrote:
> 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).
Ah, OK. To explain my interest a bit, which I hope will eventually
explain my question...
I was playing a week or so ago with my FR as a GPS receiver over
bluetooth, connected to my N800 (running maemo-mapper). It all works
beautifully, but to reach that point I had to switch from (ogpsd +
fso-gpsd) to gpsd, because (at least in Debian) gpsdrive (which
converts the gpsd TCP protocol to Bluetooth GPS) is apparently not
compatible with the gpsd TCP protocol that fso-gpsd produces.
When using gpsd, FR applications that use the TCP protocol - like
tangogps - still work very nicely, but those that use the FSO D-Bus
API - like Cellhunter - do not.
So that left me thinking:
- given that gpsd already existed, and appears to Just Work on the FR,
I wonder why FSO decided to write ogpsd + fso-gpsd from scratch?
- for the future, perhaps a better overall solution would be
- something like the inverse of fso-gpsd, i.e. which translates from
the gpsd TCP protocol to the FSO D-Bus API
- or alternatively, add the FSO D-Bus API to gpsd.
(This would need thought to allow automatic powering on and off of the
GPS device, but I think that's soluble.)
So it's interesting to hear that SHR and FSO2 might be moving in a
direction that sounds like this.
More information about the community