Bugzilla – Bug 361663
Wrong total remaining battery time of "Powersave Informations Dialog" on HP Compaq nx6125
Last modified: 2008-06-21 11:03:14 UTC
This is the continuation of Bug 347219 I'm running openSUSE 10.3 x86_64 with the newest patches on a HP Compaq nx6125 notebook with a primary and an additional travel battery. When the Primary battery is full and the Travel battery is discharging, the remaining battery time of both batteries (Travel + Primary) is always as big as the remaining battery time of the discharging Travel battery. With former versions of OpenSUSE, this worked, I remember. Before closing this bug again with the words "there is no way to calculate the time correctly for both batteries atm.", please read this: Here'is a better method for calculating the total remaining battery time (t12) of the primary (B1) and the travel battery (B2) together: P=U*I <=> I=P/U W=P*t Q=I*t <=> t=Q/I t=Q/I=Q*U/P case B1 discharging, B2 charged: case B1 charged, B2 discharging: t12 = t1 + t2 = Q1/I1 + Q2/I2 = Q1*U1/P1 + Q2*U2/P2 => assuming that P=P1=P2 over remaining time, assuming that U is constant over remaining time (I know in reality, U decreases with decreasing remaining time ;-) => (Q1*U1 + Q2*U2)/P => assuming that I1=0 or I2=0 => t12 = (Q1*U1 + Q2*U2)/(U1*I1 + U2*I2) where t12=total remaining battery time of primary and travel battery together Q1=/proc/acpi/battery/C17B/state:remaining capacity Q2=/proc/acpi/battery/C17C/state:remaining capacity U1=/proc/acpi/battery/C17B/state:present voltage U2=/proc/acpi/battery/C17C/state:present voltage I1=/proc/acpi/battery/C17B/state:present rate I2=/proc/acpi/battery/C17C/state:present rate Please don't hit me, I know, that this is only an approximation (but much better than the status quo of "KPowersave Informations dialog"s total remaining battery time, if two batteries were residing in a notebook ;-) If you want more precision, you have always got to record, keep and evaluate the last complete U-Q-diagrams of both batteries to calculate the integral (assuming that this graph is independent from the I-t-diagrams ;-) case B1 discharging, B2 discharging: (perhaps, no notebook has this discharging design ) t12 = t1 * t2 = Q1/I1 + Q2/I2
Created attachment 194782 [details] Screenshot from "KPowersave Informations Dialog" with wrong total battery time
Created attachment 194783 [details] Output of command "grep . /proc/acpi/battery/*/*"
1) Your assumptions are wrong. at least the vast majority of laptops don't have a rate for the battery which isn't discharging. 2) HAL don't have a 'overall battery' object which could handle this and it's a) not easy to implement into the existing structur and b) I'm not sure if this is really wanted 3) I don't like to add this to KPowersave because it make it more complex then really needed (because it would need to catch and handle all the existing corner cases, need code for smoothing the time etc.) 4) this is (because of 1-3) a WONTFIX for 10.3 and not sure if we implement it into 11.0 since there are more important things like the QT4/KDE4 port.
You don't need the rate for the battery, which isn't discharging, the "present rate" of the discharging battery is simply 0. You only need the "remaining capacity" and the "present voltage" of the battery which is discharging, you mean that one or both of this values aren't available?
sorry, correction: ... the "present rate" of the not discharging battery is simply 0.
Also this assumtion must not be correct. Battery could have no voltage (as rate) info until charging/discharging (we already seen such cases) and they could maybe have (theoretically) different volatage values (because such calculation have to work with all kind of batteries as e.g. als UPS) This all is really complex (which several corner cases) and at least KPowersave don't rely on time information for any of it's actions. It only rely on the percentage info which is correct. So it's more nice to have (which means it has atm no priority, sorry)
Ok, you're right, under this circumstances my proposal would be too far away from a universally valid solution. I'm at a loss how the solve the problem of the missing "present voltage" value...
This need to be fixed in HAL or may in an other upcomming powermanagement daemon in the future. I close this bug with FEATURE for now until we have something usefull.
Btw. I filled a fate request #303749 for this feature.
*** Bug 399799 has been marked as a duplicate of this bug. ***
Hi, The disposition of this bug has been ... bugging me ... :) ... for a while. I don't think it should be marked as an enhancement. FWIW, on this laptop, when I'm on battery (I have two batteries) and I'm running a Windows Virtual Machine, it correctly detects both batteries and displays an accurate time remaining. Further, when I used to use Windows (albeit on on this laptop), it would successfully report `time remaining' when I had two batteries. I'm going to mark this as a `normal' bug and if it's overwritten, well, at least I said what I wanted to say. :) btw, I do appreciate everything the good folks have done with this latest release. It's quite nice.
This is an enhancement because we filled a FATE request for it. Btw. the bug is closed, changing the severity make no sense.