Month: March 2007

g-p-m test suite

In SVN trunk, gnome-power-manager has grown a test suite. Executing “test/gnome-power-self-test –all” executes 100 self tests on some of the key GObjects, testing for things like numerical accuracy, segfaults on error conditions, some parts of the DBUS interface and other useful stuff like that. The output is pretty crude, something like this:

…
> check #19     GpmArray         :      clear array……OK [cleared]
> check #20     GpmArray         :      get cleared size……OK [get size passed]
> check #21     GpmArray         :      save to disk……OK [saved to disk]
> check #22     GpmArray         :      load from disk……OK [loaded from disk]
> check #23     GpmArray         :      get file appended size……OK [get size passed]
> check #24     GpmArray         :      interpolate data……OK [interpolated]
> check #25     GpmArray         :      limit x size……OK [limited size X]
> check #26     GpmArray         :      limit x width……OK [limited width X]
> check #27     GpmArray         :      test copy……OK [copied]
> check #28     GpmArray         :      uniform weighted average……OK [averaged okay]
> check #29     GpmArray         :      integration down……OK [integrated okay]
…
> test passes (100/100) : ALL OKAY
…

It lets me continually add features, hopefully without regressing. If I process a crasher bug in bugzilla that could have been tested for and prevented, I add it to the self test program so that any refactoring in the future does not re-introduce the bug.
This found even the simplest functions of gnome-power-manager were suffering from bugs really hard to pin-point in real world use. I'm also adding more and more tests everyday to the test program as some of the nastier bits of g-p-m (GpmPower, GpmBattery) get refactored into nice clean GObjects.
Hopefully this refactoring and restructuring of g-p-m will allow me to just slot in the profile code, and everything will “just work”, with less memory and less complexity. Let's wait and see.. :-)

Multiple battery devices

GNOME Power Manager supports merging multiple laptop batteries into one virtual battery for the time remaining calculation and also the status area icon. Unfortunately my new statistical driven approach breaks with primary batteries being removed and inserted, as we'll need some sort of profiles for “one battery” or “one battery plus extra battery” just to make the new code work. Unfortunately, my Lenovo only has the one battery, with no option to extend it. Now, long shot: Does anybody have an old laptop that they do not want that they could send to me? It would need to have two batteries expressed in ACPI (with at least 10 minutes of charge in both), with the ability to remove one at run-time. It doesn't matter if the machine is 400MHz with a smashed screen, any old test machine would be great. If I get my hands on a multi-battery laptop, then the new profile code work will work really well with two batteries. Sorry if this sounds cheeky, but it's really hard to code for a situation you can't test for.

We suck less, although the UI could do with some work…

The new profile code in gnome-power-manager allows us to calculate the amount of time the battery has until charged, and also the amount of discharge time you would have if you disconnected the ac adapter now.

Is this useful to expose to the user? If so how? What about a tooltip “Laptop battery 48 minutes remaining until charged (64%), currently provides 1 hour 45 minutes discharge time“. I really suck at UI wording, so better ideas please.

gnome-power-manager time remaining profile code

GNOME Power manager often sucks at predicting the amount of battery time you have left. To fix this, I've been working on a new time remaining profile class for gnome-power-manager. I'm using a self-adjusting discharge and charge profile that adjusts for the specific battery and computer that's being used, and also how it is being used. Why is this important?

  • BIOS's frequently lie to us pretty badly.
  • So called “smart” battery discharge chips are often really, really dumb.
  • Batteries sometimes have old or degraded cells that really don't hold much charge.
  • Batteries discharge faster if you are typing than if the computer idle. There's no point knowing how much time you have when idle, users want how much time they have when the computer is being used like normal.
  • Some batteries (like the OLPC or N800) don't give us much useful information and we have to be a bit clever.
  • Some BIOSes from Lenovo are REALLLLLY REALLLLLY BROKEN.
  • Sometimes machines with multiple batteries discharge in series or parallel, which completely change the way we calculate total capacity, and it's often pretty random when they change over.
  • We have a lot of floating point processing power available for some fairly advanced statistics when we are in userspace, rather than in the hardware or in the kernel.

So basically I suggest ignoring the battery capacity, and just watch how long in seconds it takes to change by each percentage point. Doing some clever rate calculations, and with enough duplicate data (which only takes 2 or 3 charge discharge cycles) the time is pretty easy to get. And, wow, it works – remarkably accurately, and more and more accurate with each charge/discharge cycle.


Sub-screenshot of data-profiling

Main problem: How do we prevent collecting bad data? Lots of things break the accurate profiling.

  • The OpenGL screensaver starting
  • The laptop screen doing DPMS off
  • Beagle doing a re-index while charging (large effect)
  • Lots of CPU load (like a kernel compile)
  • Large temperature variations.

So far I'm just rejecting any data collected during a load > 10%, or when the backlight is off, or while the session is idle. Ideally what I would like is are [Profile Start] and [Profile End] buttons that turn off all the power saving stuff and beagle/trackerd cache updates just until we have some sensible data, which we only need to do once. Ideas welcome on how to integrate this with any possible UI.

All of the new stuff is already in gnome-power-manager trunk, but some bits won't work unless you have pretty similar hardware to mine – plus it's got pretty minimal testing. The time remaining in the UI is currently all still based on the old method, but this new method will probably be selectable via gconf. So things are getting better.

autofoo-1.10 and evolution

I'm running Fedora Rawhide. I'm having problems building packages such as HAL (specifically make distcheck) using aclocal-1.10 and automake-1.10. If I manually use the *-1.7 packages things build like they used to, but of course 1.10 is always chosen over 1.7 to build rpm's and thus the rebuild fails like this:

gtk-doc: Compiling scanner
mkdir .libs
 gcc -g -O2 -Wall -Wchar-subscripts -Wmissing-declarations -Wnested-externs -Wpointer-arith -Wcast-align -Wsign-compare -c hal-scan.c  -fPIC -DPIC -o .libs/hal-scan.o
hal-scan.c:5:25: error: glib-object.h: No such file or directory
hal-scan.c:7: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'libhal_psi_get_type'
hal-scan.c:8: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'hal_device_store_get_type'

Anyone come across this before, or have any ideas on how to fix this?

Also evolution has been broken on rawhide for the last week or so for me. Don't you just love rawhide.

Handling GNOME Bugs

The new GNOME crash handler is great. Unfortunately I get quite a few duplicates every day of a particular bug that has recently been fixed. I'm sure I'm not the only developer with this problem of fighting with bugzilla.

Perhaps the wording of the crash dialog should say:

What were you doing when the application crashed?
You should aim to provide developers with enough information to replicate the crash, and not details about what you are drinking.
Please can you check the product bugzilla page to check for duplicates before sending crash details. [Check Now]

Or, even better:
A similar bug has already been reported and the developers have released a fix. Please make sure your system is up to date, and if so file this in your distribution bug tracker.

Or at least:
The application crashed and you have no debugging symbols; this bug report is both a waste of time for you and the application developer who will just ask for a better stacktrace with debugging symbols.

Or in an ideal world:
The application crashed and you have no debugging information available. The required files have now been automatically downloaded, and if the bug happens again your bug report will be sent to developers.

Epiphany and print to PDF

Epiphany is the best browser available for Linux in my opinion, as it's nicely integrated with GNOME, quick to start and is really easy to use.

One major feature is missing: Print to PDF… It gives me the option to print to PS, but I can hardly send a huge PS file to my parents. How come the GNOME web browser can't give me the printing options that all the other GNOME software gives me?

There are two bugs open, one with a trivial patch, so maybe we can fix this for GNOME 2.18?

SVN and ignoring files

Today I branched gnome-power-manager for 2-18. Expect a fair bit of refactoring on trunk, and the self test code to grow in complexity. SVN is different. Why is is so hard to set svn ignore properties? It seems so difficult compared to CVS. Google isn't being helpful either. How for instance do I set the svn:ignore property on “test/.libs” without upsetting the other ignored status of the other files? There must be a GUI for this somewhere. Any ideas?