Bug 169158 - handling of multiple laptop batteries is less than ideal
handling of multiple laptop batteries is less than ideal
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: gnome-power-manager (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: John (J5) Palmieri
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-23 15:41 EDT by Jeremy Katz
Modified: 2013-03-13 00:49 EDT (History)
3 users (show)

See Also:
Fixed In Version: fc5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-25 10:58:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jeremy Katz 2005-09-23 15:41:47 EDT
If you have more than one laptop battery, the time remaining which is shown only
takes the currently discharging battery into effect as opposed to the sum of the
two.
Comment 1 Bill Nottingham 2005-09-23 21:53:49 EDT
This is probably read directly from HAL...
Comment 2 Richard Hughes 2005-09-25 18:28:20 EDT
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.
Comment 3 Richard Hughes 2005-09-25 18:41:22 EDT
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.
Comment 4 Jeremy Katz 2005-09-25 20:33:10 EDT
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 ;)
Comment 5 Richard Hughes 2005-10-11 04:45:15 EDT
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.
Comment 6 Richard Hughes 2005-11-06 12:14:56 EST
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).
Comment 8 Jeremy Katz 2006-05-25 10:58:38 EDT
I think this was fixed, but I no longer have a laptop with two batteries to say
for sure :-/

Note You need to log in before you can comment on or make changes to this bug.