[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