[Gta04-owner] qtmoko-navit: Gui blocks in town search in binfile maps.
Stefan Wildemann
stefan.wildemann at metalstrolche.de
Mon Mar 4 15:36:08 CET 2013
Hi together,
finally I was able to compile qtmoko + qtmoko-navit. But it was slow as
hell (4 days for qtmoko).
Could someone doing native builds for armhf on qemu post the used qemu
configuration for armhf?
Is it possible to just build parts of qtmoko say e.g qwhereabouts?
About the navit problems I found so far 2 problems.
First, search is unusable because for whatever reasons the Idle event
doesn't get triggered. If it
is changed to a cyclic half second timer then at least search works.
This is NOT a solution yet, but way
better for those wanting to actually use navit now. I'll continue
investigation here.
No patch for that. Just alter line #883 in
navit/navit/graphics/qt_qpainter/graphics_qt_qpainter.cpp of radek's
qtmoko_hack2 branch to say"return (struct event_idle
*)event_qt_add_timeout(500, 1, cb); "
Second problem is the qwhereabouts-plugin neogpsplugin. Currently it
hooks to gpsd via gpspipe.
Additionally it triggeres rfkill for gps device. Unfortunately gpsd
doesn't immediately close the gps device when
it looses connection. So closing neogpsplugin interferes with gpsd. This
may lead to strange gps behaviour.
Do we need these "manually" calls to rfkill at all? I always thought
kernel would do this now. If yes then we could
use gpsd hook instead.
As we're having gpsd anyway, I switched to directly using qwhereabouts
on gpsd.
Unfortunetly this doesn't work out of the box yet as qwhereabouts sends
a malformed request to gpsd. It seems
gpsd doesn't like 0x0a chars within one request string.
I'm going to fix this, but as long as compiling qtmoko takes around 4
days I won't have results soon.
Greetings
Stefan
More information about the Gta04-owner
mailing list