GNOME Bugzilla – Bug 163013
Battery monitor doesn't update power status after resume
Last modified: 2005-08-18 14:58:29 UTC
From Fedora: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=139253 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. So, reading the code we only update the AC state when we get an "ac_adaptor" event but we update the battery state both when we get a "battery" event and also every 30 seconds. However, AFAICS, you don't get any ACPI events on unsuspend (which sucks). It probably makes sense to read the AC state in acpi_linux_read() and kill update_ac_info(). That would prevent bugs like bug #157614 too.
The workaround is to restart ACPId after resume. Mark, I figure we can probably poll for this every 30 seconds. Eventually all of this kind of crack will be moved into HAL or PowerManager. Got a patch?
Created attachment 35820 [details] [review] Untested patch Dunno, I think I'd do something like this.
*** Bug 301808 has been marked as a duplicate of this bug. ***
I have encountered the same problem. I would already be happy if I can tell battery applet to update its status. Since one has to do things like syncing the system clock with the hardware clock upon resume anyway, can the battery applet simply refresh its status up receipt of a, say SIGHUP? The cpu frequency applet, for instance, reacts usefully to signals as well. In that case, I could simply include a killall -HUP battstat in my resume script.
*** Bug 309398 has been marked as a duplicate of this bug. ***
I wouldn't want to see the attached patch verbatim, as it removes the immediate response to the event when possible. Why take out the on-event reading of AC state? Adding the reading of AC state with battery state seems fine to me. You still get immediate response when feasible, and the whole resume issue and broken ACPI implementations still get addressed. I also very much like the idea of responding to sighup to update all info for resume scripts, it allows an immediate update on resume in a sensible way.
Just merged in a Debian vendor-patch to fix this (has been in use for some time by a lot of people and seems to be working).
*** Bug 313070 has been marked as a duplicate of this bug. ***
*** Bug 313564 has been marked as a duplicate of this bug. ***