maemo.org Bugzilla – Bug 3981
liblocation possibly relies on application using the default GMainContext
Last modified: 2010-02-12 13:22:47 UTC
You need to
before you can comment on or make changes to this bug.
liblocation-dev and liblocation packages of version 0.30-1
STEPS TO REPRODUCE THE PROBLEM:
Test application for liblocation as it can be found here
http://svn2.assembla.com/svn/TriageTag/gpsd-cli/trunk/src/main.c (not my code).
The code will be changed to use a custom GMainContext for GMainLoop, by adding:
/* After declaration of global variable "loop" */
GMainContext *context = NULL; /* Added! */
GMainLoop *loop = NULL; /* Unchanged! */
/* Creating custom GMaiNContext instance and assign it to our main loop */
context=g_main_context_new(); /* Added! */
loop = g_main_loop_new(context, FALSE); /* Changed! */
Everything works. Especially callbacks get called.
After switching to a custom GMainContext callback are not called anymore.
EXTRA SOFTWARE INSTALLED:
no special software
It seems like the implementation of liblocation relies on the default main
event loop of Gtk, based on the default GMainContext. If a custom context is
used internal "event handling" sends events to the wrong main loop resulting in
events getting lost.
I see no work around an the application side. This blocks usage of liblocation
for all applications not using the default context. This may especially block
usage of this library from non-Gtk applications. This may in fact also be a
problem for Qt applications (the problem with using the default context and
default main loop in this case is, that Gtk installs an callback that handles
X11 events conflicting with similar code in the other GUI framework).
Since liblocation does not seem to be free, I cannot check the code so this is
just an assumption. A possible fix is to make it possible for the application
to pass a custom GMainContext to the subsytsem. Note that using custom Context
seems to be allowed at other places of the maemo environment. For example
libosso allows to pass a custom context, too.
Any hints regarding a workaround will be apreciated.
> EXPECTED OUTCOME:
> Everything works. Especially callbacks get called.
FIXED in Fremantle.
Sadly given example (link and patch) still does not work with pre-production
device and final SDK. I will attach patched code and a simple makefile.
GPS daemon seems to get started by callbacks are never called. As said before
this may stop any non-gtk application from using liblocation. This may include
Funny that http://talk.maemo.org/showthread.php?t=33657 references
which in turn includes a Gtk example. I'm however positivly suprised that this
document also contains a link to my GPSJinni application. However because of
this bug I have problems getting it to work under fremantle (in diablo I used
liblocation for starting and stoping the daemon, but acces gps dameo diretcly
using libgps. However this is not possible anymore since the library is not
available in fremantle).
Created an attachment (id=1582) [details]
Patch example source from link given in bug report
Created an attachment (id=1583) [details]
Makefile to quickly build example attachment
"Reason for this is that gconf in Maemo uses D-Bus and it is not possible to
change that to use non default main context (int-106889).
There is possible hack to iterate gconf maincontext manually but that will
drain battery and is not recommended."
(In reply to comment #5)
> "Reason for this is that gconf in Maemo uses D-Bus and it is not possible to
> change that to use non default main context (int-106889).
> There is possible hack to iterate gconf maincontext manually but that will
> drain battery and is not recommended."
So how than should Qt application access liblocation (since the possibly have
the same problem)? How does ovi-map do it? They use GMainLoop, too - but
likely also with a custom context, or do they not (I had problems to use the
context of Gtk because Gtk then tries to filter events from my event loop)?
IT is also not true that DBus cannot use a non-standard context (or was it
meant that GConf cannot be made to use DBus with an non-standard context?)).
You can use
to get DBus Connections for a non-standard context.
(..and how was this ticket ever set to FIXED in fremantle <grrr>?).
This is still being discussed...
The current, NOT RECOMMENDED workaround will iterate gconfs default maincontext
manually 10 times a second. You can pass GMainContext pointer to
LocationGPSDControl object with example g_object_set(G_OBJECT(control),
"maincontext-pointer", ctx, NULL);
Problem with this is power consumption since device can't sleep when having
timeout for iterating gconfs maincontext manually.
I was able to fix the problem in my software by switching to use the default
Gtk context. However since this is tricky I would still like to see this fixed
sometime in the future - at least as long libosso signal non-default context
usage is OK and documentaiton claims to not only support Gtk and/or Qt.
"Workaround: Iterating default maincontext manually from software that uses
liblocation. Then iteration can be done as often as required. Then you have to
remember that some other applications might get/require fixes more often and
your application will get fixes only when you iterate default maincontext."
"The current behaviour is that custom GMainContext is iterated once a second.
This is a balance between functional correctness and battery. Application has
chance to iterate the context at any interval.
Basically, we see the current solution is the best working one, and no better
solution is available. -> CLOSED"