Looks good to me.
Richard Hughes wrote:
On Sat, 2009-01-24 at 19:37 +0300, Alexey Starikovskiy wrote:
I don't understand, why this guesswork over fully charged? If you cannot
detect fully charged, then *don't*.
But if you must sinthesize it, and you can get an up-to-date "last full
capacity" from the battery when comparing, I suggest:
full = (current capacity == last full capacity) && !charging &&
!discharging
certainly, 90% is wrong, but 100% makes a day...
I think we need some sort of logic like this.
That would *still* be wrong in a few corner cases, but at least they're rare
corner cases that happens only when the pack recalibrates its fuel gauge.
full in this case is not exact term. As any other term beside current_now and voltage_now.
Capacity of the battery is estimated, so any number that was depending on it, is estimated too.
Right, never underestimate the brokenness of some people's batteries out
there. Coupled with broken BIOS's, some of the fix-up code in HAL is
'interesting'. I think all the fix-up code in HAL belongs in in the
kernel.
If there isn't a reliable way to detect the "full" state, just drop the
fully charged detection altogether.
People are used to see "full" state of the battery. I think we could tolerate not-full-enough
for sub-second interval instead of dropping full state altogether.
We shouldn't drop the full state, we should just add some metric like
above. What about something like the attached (untested) patch? Would
something this be accepted?
Richard.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
