Bi-weekly OpenMoko community update

Joshua Layne joshua at
Tue Oct 16 18:18:30 CEST 2007

Derek Pressnall wrote:
> If the gpsd falls into catagory 3 (and not 2), then for me that is ok,
> as long as it is bug free, will work with updated kernels, and has a
> defined api for talking to it from other apps.  In that case, I can
> treat it as if I'm using a gps chip that spits out the protocal that
> the daemon is spitting out. (I assume that is what the daemon is for,
> to take the propriarity api on the chip and convert it to a
> standards-based api).
gpsd does a bit more and a bit less than that - most chips already spit 
out NMEA 0183 sentences.  gpsd wraps these and provides a shared 
interface to the gps, so that apps don't need to bind to a comm port and 
multiple apps can leverage gps data.  gpsd will also run in some binary 
modes (SiRF and garmin, perhaps others) and will signal to switch 
between binary and NMEA modes.  Otherwise, diagnostics , gpsfake, etc...

more info (if you are interested) at

The 'bug free' is the part that I would be most worried about - often 
the bugs are only discovered after extended use, because real users are 
capable of getting machines into states that testers couldn't dream of 
:) although not so much with gpsd, which seems to be pretty robust - I 
have had problems with older versions where it did not suspend properly 
(and was extremely difficult to kill), but I never really sorted whether 
that was gpsd or something else.
> Now a secondary purpose of having source availability is to study the
> code to improve my programming techniques.  So having a closed gpsd
> doesn't help there.  But it doesn't affect the primary purpose. (Of
> course, other people have different primary purposes than me, so this
> won't apply to them).
The core of gpsd is totally open for code review, I think the closed 
binary only applies to the gllin piece, but I could be mistaken.


More information about the community mailing list