MC Navi released

[Neil Jerram]

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

Regards,
        Neil