Software is (still) alive!
lists at nanl.de
Fri Nov 13 09:15:40 EST 2009
it has been a bit quiet around the software last days.
However that does not mean we're stalling - far from it!
We are hacking around day and night and much happened!
So - what happened? :)
== power management and -consumption
Lars wrote code for power management on the Ben NanoNote!
He also benchmarked the power consumption of the Ben NanoNote in several
hard - and software states with and without his power management
Here are the results:
| without pm-patches | with pm-patches |
Under full load | 162 mA | 160 mA |
Idle black screen | 95 mA | 94.5 mA |
Idle white screen | 93 mA | 92 mA |
Idle colored screen | 105 mA | 104 mA |
Display off | 64 mA | 52.5 mA |
Suspended | N/A | 9.8 mA |
== "package features" within OpenWrt
Since the NanoNote is the first device which runs GUI-applications
within OpenWrt on top of DirectFB and not X11, we had to rethink how GUI
applications can be used with Xorg _and_ DirectFB within OpenWrt in a
We introduced so called "package features".
In this use case the package feature "drawing-backend" was created,
which can be "DirectFB" or "libX11".
That way supported applications can be configured easily via the
ncurses-based menu to get compiled and linked against either DirectFB or
In this context, all related existent packages were adjusted (as
directfb, libX11, gtk, cairo, pango, atk, fontconfig, etc.)
== ported and committed packages to OpenWrt
All qi-related OpenWrt-packages were cleaned up and committed, e.g.
c++-bindings for <glib>, <cairo>, <pango>, <gtk+>, as well as <gtkhtml>,
a lightweight HTML rendering engine to render HTML within
<vido> - a proof-of-concept zimfile-reader/viewer based on gtk2 and
gtkhtml, which may be used as wikipedia offline reader/viewer - is
ported as well.
I also ported a set of games provided by the <gnome-games>-package which
are usable on the Ben NanoNote, as <glines>, <same-gnome>, <gnomine> and
as always - of course we're also facing problems and any help here is
Unfortunately vido does not work properly yet. It segmentation faults in
certain cases. This may be caused by vido itself or one of it's
dependencies (e.g. the c++-bindings it is using like gtkmm, glibmm,
pangomm, cairomm, etc.).
There seems to be a "design problem" with gconf/dbus which is causing
applications using gconf not being able to communicate with the gconf
database without a hack.
Applications using gconf automatically try to spawn a gconfd-process if
there's no one running yet. However the gconf does not get launched.
After some debugging I found out gconf itself is trying to spawn a
dbus-process with "--autolaunch" as argument.
"dbus --autolaunch" however is only supported when dbus is compiled with
X11-support. As X11 may not be used (as in our case), this type of
launching dbus is not available which is causing gconf not to get
started properly which causes applications using gconf not being able
communicate with the gconf-database.
The mentioned "hack" to workaround this issue is spawning the
dbus-process manually and tell the system via environment variables that
a dbus-process is running.
That way gconf does not need to "autolaunch" one by itself.
To do so execute the following line before running any application using
eval `dbus-launch --sh-syntax --exit-with-session`
Have a nice weekend and keep on hacking :)
This email address is used for mailinglist purposes only.
Non-mailinglist emails will be dropped automatically.
If you want to get in contact with me personally, please mail to:
mirko.vogt <at> nanl <dot> de
More information about the discussion