Proposed fixes for ACPI backend
Ryan Lortie
desrt at desrt.ca
Mon Sep 5 10:08:45 PDT 2005
Hello Everyone.
As per:
http://bugzilla.gnome.org/show_bug.cgi?id=315259
I created a patch for gnome-applets in hopes that the 2.12.0 release
would provide a workaround for this problem. The release team, however,
appears to not want to push the changes into the release at such a late
date (and I don't blame them -- I'm only 5 hours away from rolling the
final tarball). One of the release team members suggested that the
correct place to fix this bug is in HAL and he's right.
HAL allows the reported charge to exceed the reported 'last full'
causing the battery status applet to show 204%. Again, this is the
fault of crackrock ACPI implementations but it's something that HAL
should be able to deal with.
I fixed this in acpi.c and at the same time I made some other fixes:
- The fix mentioned above to clamp current capacity to never exceed
full.
- A fix to make sure that the voltage used to perform the calculations
on current capacity never exceeds design voltage.
- A fix to battery_refresh() to make it match the checking that
was already being done in battery_refresh_poll() (sorry that I
missed this in my last patch....)
- A fix to ensure that if design voltage is unknown then we also never
use current voltage (even if we know it!). This is important to
avoid having our current charge level vastly exceed the design
capacity (which will have been calculated using 1mV).
- Variable rename to indicate that the quantities that we're dealing
with are not mWh but rather can sometimes be µWh (or even just mAh
in the case that we don't know voltage and just multiply by 1).
As with all ACPI changes, my work is *completely* untested (since I
don't have an ACPI laptop) so please review thoroughly :)
Cheers.
More information about the hal
mailing list