Red Hat Bugzilla – Bug 139253
battstat-applet-2 does not correctly reflect power status after resume
Last modified: 2007-11-30 17:10:54 EST
The battery applet does not correctly reflect the status of power on a
laptop system after the system has resumed from a suspended state. The
applet has an icon to indicate whether the laptop is on battery on
or AC power. This icon remains in the state it was in when the system
was suspended, presumably because it relies on events to notify it
of a change of state. If the system is resumed with the power system
in a different state to when it was suspended, the applet continues
to reflect the wrong state, and the battery charge/discharge time
calculations give confusing results because the battery charge is
changing in a different direction from the direction the applet expects.
This problem was observed on an IBM Thinkpad X24 using ACPI.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Connect the system to AC power.
2. Suspend the system.
3. Disconnect from AC power.
4. Resume the system.
Actual Results: The battery status applet show an icon indicating
that the system is on AC power, and has a tool tip giving a time that
the battery will take to be fully charged.
Expected Results: The battery status applet should indicate that the
system is on batter power, and the tool top should give the time
remaining before the battery is exhausted.
give you after you've resumed?
/proc/acpi/ac_adapter/AC/state gives the correct status after resuming.
if the AC adaptor is connected, and:
if its not connected.
I have a similar problem, might be related:
Power on my laptop from cold but with weak battery (Fujitsu Amilo D,
using ACPI, was working perfectly with FC2) and the battstat applet
says "98% charged, on ac power" when the machine has been running off
battery for an hour.
Then it corrects itself (ie, 15% charged, battery discharging) when I
manually query /proc/acpi. ("cat /proc/acpi/battery/BAT1/state" or
Battstat applet v2.8.0, kernel 2.6.9-1.681_FC3
Logged this bug upstream: