battery.remaining_time.calculate_per_time

[Richard Hughes]

On Thu, 2007-04-26 at 10:14 -0700, Artem Kachitchkine wrote:
> Is this property ever set to true in practice? I heard from someone
> (but haven't verified) that when the battery gets close to fully
> charged, at around 95%, the precise calculation sometimes causes
> remaining time to jump backwards (i.e. increase), and the guessed
> value seems to work better in that case. What are your experiences? 

For all new versions of g-p-m, I'm completely ignoring the HAL
time_remaining property, as more often than not it's broken (with funny
race conditions, or the hardware just lying to us). I'm instead
self-profiling the battery and doing some fancy floating point
integration to get a much more reliable reading, based on the fact that
most "smart battery controllers" are actually _unbelievably_ dumb.

My personal vote is if the hardware isn't providing the data, then we
shouldn't try to guess it - as in doing so we get it wrong a lot of the
time. Using the rate is a good compromise, but only about 50% of
notebooks in my experience report the rate accurately.

I know this might contradict some of the stuff I said about calculating
the time on this list, but it's the conclusion I've come to after years
of bug reports.

<controversial>
I think the concept of "time remaining" depends on so many session
things (network connection, DPMS panel blanking, backlight
brightness...) it makes sense to do this higher in the stack where we
have all the info.
</controversial>

Richard.