:: Re: [maemo-leste] GPS fun on Droid …
Top Page
Delete this message
Reply to this message
Author: Merlijn Wajer
To: Pavel Machek, maemo-leste, tony, sre, nekit1000, mpartap, martin_rysavy
Subject: Re: [maemo-leste] GPS fun on Droid 4 and leste
Hi Pavel,

On 12/07/2020 12:06, Pavel Machek wrote:
> Hi!
>> user@devuan-droid4:/my/tui/lib$ xgps
>> Traceback (most recent call last):
>>   File "/usr/bin/xgps", line 30, in <module>
>>       gi.require_version('Gtk', '3.0')
>>  File "/usr/lib/python2.7/dist-packages/gi/__init__.py", line
>>  129, in require_version
>>  raise ValueError('Namespace %s not available' % namespace)
>>  ValueError: Namespace Gtk not available

> sudo apt install gobject-introspection gir1.2-gtk-3.0
> can fix this problem, but then I get
>   File "/usr/lib/python2.7/dist-packages/gi/overrides/GLib.py", line
>   669, in <lambda>
>       func_fdtransform = lambda _, cond, *data: callback(channel,
>   cond, *data)
>     File "/usr/bin/xgps", line 870, in handle_response
>         if self.daemon.read() == -1:
>       File "/usr/lib/python2.7/dist-packages/gps/gps.py", line
>   271, in read
>       self.unpack(self.response)
>         File "/usr/lib/python2.7/dist-packages/gps/client.py", line
>   167, in unpack
>       raise json_error(buf, e.args[0])
>       gps.client.json_error

> ...which I believe is droid4-specific. It hangs after restart.

I believe Tony has said that there is a bug (either in kernel or gpsd)
that makes the GPS hang on restart. His suggested fix was to put a fifo
in between gpsd and the kernel.

Some other relevant logs from IRC (sorry, in a bit of a rush, but you
seem to be working on it now, so want to respond in a timely manner)

> 15:14 < tmlind> buZz: yeah gps is there, just point gpsd to /dev/gnss0
> 15:14 < buZz> sweet!
> 15:14 < tmlind> buZz: it will take a long time currently to get the fix initially as the agps support is not yet ready
> 15:15 < buZz> yeah thats ok
> 15:16 < tmlind> buZz: and you should use a recent gpsd, at least 3.20 is known to work, 3.18 i think had a bug where only one client could use the output and then gpsd had to be restarted
> 15:16 < tmlind> or else it was a kernel bug that already got fixed somewhere, sorry no other details
> 15:17 < tmlind> and modprobe gnss-motmdm may be needed if you don't see /dev/gnss0
> 15:18 < tmlind> also, looks like gpsd can be just running, it behaves for pm as long as the option for -n is never specified in gpsd.conf


> 17:05 < Wizzup> tmlind: wrt gps on the droid, you said there is currently a bug that allows opening /dev/gnss* only once?
> 17:09 < tmlind> Wizzup: i think that was a bug in gpsd, did not happen last time i tried. if you hit that one, opening secondary clients like gpspipe -R won't output anything
> 17:09 < Wizzup> ah, so it's not a kernel problem, ok
> 17:10 < Wizzup> once maemo-input-sounds is done (hopefully tonight) I will work on location stuff in case I can go on vacation and need gps, or until fmg is done with abook and we then look at rtcom
> 17:10 < Wizzup> in any case, I was wondering what the gps status is, but I think we'll start gpsd on demand, so that's fine
> 17:11 < Wizzup> from a pm pov, I assume closing the fd will stop gps recv?
> 17:11 < Wizzup> also, this is on the wiki: 22:30 < tmlind> hmm there's a probably kernel gnss bug for gsp access fyi, you can currently only open one connection before you have to restart gpsd :)
> 17:13 < tmlind> Wizzup: yeah so if hiking, you probably want to modprobe gnss_motmdm rate_ms=3000 or even higher to allow the soc to sleep inbetween
> 17:14 < tmlind> Wizzup: the default gpsd options only open device if there's a client and times out automatically

Hope this helps.

And yeah, setting up gpsd automatically, especially if it all behaves pm
wise, seems like a great next step.