This is probably read directly from HAL...

It should! The code is there to add the two batteries run-times to make the
total time. Could you send a full bugreport to me please:
http://gnome-power.sourceforge.net/report_bug.php -- thanks.

Ohh, thinking more I see the problem. The discharging battery does not have a
time-to-discharge value as it's not *discharging*. And there is no rate
information for the non-discharging battery as it's not being used. Is there
*any* clever way HAL could work this out? Maybe using the assumption that
{battery2}.last_full / {battery1}.rate = {battery2}.remaining_time? I don't know
if that is a valid assumption.
The code has been tested with multi-battery setups, but the only testing has
been done where the two batteries discharged simultanously, not one after the other.
Ideas welcome.

I think assuming the rate is constant independent of the battery is perfectly
valid.  At least, it's as valid as anything you can do in that case.  It also
seems like that's what everyone else does ;)

I'm working on a complete solution. In HAL, I can create a virtual battery, with
the other batteries under the virtual object. The virtual object can then report
time_remaining, whilst the non-virtual batteries can continue to provide the data.
This lets us calculate the percentage and time remaining correctly, without
breaking API.

Can you try g-p-m CVS please, and post the output here. I'm not sure if this
should be solved properly in HAL or in g-p-m. Should HAL just report the data,
or process it and duplicate it for each battery type of the same type. I'm
erring to "fix" it in g-p-m, else HAL is going to get very muddled (taking into
account hot-plugging of batteries).

CVS g-p-m *might* properly work for you now:
http://cvs.gnome.org/bonsai/cvsquery.cgi?branch=&dir=gnome-power-manager&who=rhughes&date=explicit&mindate=2005-11-07%2009:09&maxdate=2005-11-07%2009:11

I think this was fixed, but I no longer have a laptop with two batteries to say
for sure :-/