GNOME Bugzilla – Bug 710344
Remaining time incorrect on dual battery system
Last modified: 2015-07-10 15:20:14 UTC
On my dual battery laptop (Sony Vaio Pro 13) the reported remaining run-time equals the remaining run-time of battery #1. The percentage of remaining battery power is correct sum of battery #1 and battery #2. This problem exist at least when the battery state is queried with GetPrimaryDevice over dbus. This results in a severe problem, triggering of the critical power level event, when the #1 battery gets empty, even thought the #2 is still full. Shell's ?usermenu? also reports remaining battery time incorrectly. This problem did not exist in 3.8 branch.
What's the output of "upower -d" on this system?
Created attachment 257602 [details] upower -d output
When the problem happens is better though.
Oh, and UPower 0.9.22 is broken, and a corrected version still isn't available (git 0.9 branch if you're into compiling your own software). You'll have to wait a bit to test this properly.
Please check with UPower 0.9.23, just released.
After updating to UPower 0.9.23 the problem persists. On additional note sometimes (Don't know what triggers it) the remaining time gets ridiculously high like 18h or 20h. Control center reports reaming time correctly on the power menu.
Can you attach the output of "upower -d" with UPower 0.9.23 when the problem happens?
Created attachment 257662 [details] upower -d output, v0.9.23 This is what 0.9.23 reports.
This is what's causing problems: Device: /org/freedesktop/UPower/devices/battery_BAT0 <snip> battery present: yes rechargeable: yes state: discharging <snip> energy-rate: 0 W Because the energy-rate is 0, it wouldn't have a time-to-empty at all. And the composite battery code in gnome-settings-daemon wasn't taking that into account.
Created attachment 257745 [details] [review] power: Fix time to empty with multiple batteries If one battery is draining and the other one isn't, the time to empty wouldn't be zero, but it would only match the time to empty for the single battery. Instead, short-circuit the time_to_empty re-calculation for single battery systems, and ignore the accumulated time to empty/time to full for multiple batteries and recalculate it.
Can you please test this patch? I've also push a similar patch for UPower 0.99, as the "composite device" calculations lives there now.
This patch does fix the problem indeed.
In the future, please don't close bugs as fixed if they have uncommitted patches in them.