GNOME Bugzilla – Bug 157614
battstat-applet icon not changing
Last modified: 2005-01-21 02:27:56 UTC
If you put the battstat-applet on your 2.8 gnome, and you switch between battery and AC, the applet's icon doesn't change, mantainig the initial icon. It should switch too between the two icons.
This is very likely to be something wrong with your setup. Are you using APM or ACPI?
I am using ACPI... the battstat-applet works correctly when it load, and show correct status of the battery level, but doesn't change the icon...
Are you using acpid? What version?
acpid-1.0.3
I've this bug too. If I run with the battery and plug the power the icon doesn't change. acpi displays the right informations. I need to unplug/replug the power a second time to get the change. acpid is 1.0.4
*** Bug 161761 has been marked as a duplicate of this bug. ***
I saw this bug a long time ago. I can't remember what the fix was then. What kernel are people using? It could be the name of the event has been changed (that sounds like something the kernel guys would do).
kernel is 2.6.8.1 on a hoary system for me
Can you use acpi_listen for me to listen to events coming from acpid. eg. [davyd@pingu gweather]$ acpi_listen ac_adapter ADP1 00000080 00000000 <== unplug event processor CPU0 00000080 00000000 ac_adapter ADP1 00000080 00000001 <== plug event processor CPU0 00000080 00000000 battery BAT1 00000080 00000001 <== battery charge event ... This will tell us if you're getting events from ACPId, since we rely on those to know when to parse /proc
Davyd, acpi_listen show's nothing when I unpluged/plug power. Does this have anything todo with Power Management in the processor? I had to disable PM in processor.c to stop complete lock-ups from happening.
Peter, I'm not sure of the exact specifics inside the kernel. However I know that without that event we never discover that we need to learn the new power status. The event is very important, because polling /proc/acpi is very expensive, so we should only do it when told to. Since it would appear to be a kernel bug, you could try talking to some of the kernel guys. Or you might have to patch your DSDT. Or something like that.
hi, I have exactly that same problem. I know that my acpi is "buggy" : # Enable this if you have a buggy ACPI implementation that doesn't send # out AC adapter events. This will make laptop mode check the AC state # on battery state change events as well. ACPI_WITHOUT_AC_EVENTS=1 this is from kernel feature "laptop-mode" - default is 0 .. but it doesn't work for me and I have to change to 1 to make it work. Maybe this will help a little ... Davyd, as for acpi_listen - my system told me this: # ./acpi_listen battery BAT1 00000080 00000001 <-- when I disconnect AC cable battery BAT1 00000080 00000001 <-- when I connect AC cable it looks like something is definitly wrong ... but I don't know what. BTW I've discovered that when my AC cable is connected and I start gnome, with battery-applet turned on by default, it shows that I am on AC - good... if I disconnect AC cable - nothing changed (I can still see plug icon with info "System is running on AC power") however ... if I now restart battery-applet I can see battery icon and "System is running on DC power" <-- it looks like battery-applet doesn't see changes in /proc when it's running, it only sees them when starting ... so it looks like it can't actively monitor changes of AC/DC state. I hope it will help a little with solving this. sincerly, marcyn
Marcyn. You can't monitor /proc for changes in the same way you can with other files (afaik). Instead we wait for ACPI events to tell us when to read /proc (reading /proc is expensive). Since we need to learn state, we read /proc once at load without waiting for an event, which will include the current AC power setting.
hmm why not ? I think that monitoring content of the file in /proc is possible ... but never mind ... battery-applet doesn't work that way (we don't want to change the main code of this applet, do we ? :P ) - so the question is: is there any way of making it to work with ours buggy acpi ? or it is simple not possible ... sincerly, marcyn
Actually, we do want to rewrite the applet, however we are waiting till batteries are handled by HAL. This means that HAL will send us the asyncronous events we desire, and it can handle strange power management systems and buggy implementations for us.
ok thank you for answer I and all of as who have problems with this will wait sincerly, marcyn
Created attachment 35219 [details] [review] Update AC info on battery events
Comment on attachment 35219 [details] [review] Update AC info on battery events Temporary work-around for buggy ACPI implementations that send battery events when the AC state changes.
Comment on attachment 35219 [details] [review] Update AC info on battery events Ok, since it seems a few people suffer from buggy ACPI we can perhaps add this in. IMHO, the way to do this is with a hidden field in the gconf settings for the applet, a bool workaround_buggy_acpi or somesuch. Ensure that you also add a schema for the option, indicating the default is off, and adding a useful description for what this option does.
hah ! I confirm that... it works thank you very much Daniel Brown sincerly, marcyn
Seb, after switching my laptop to Ubuntu Hoary (from Debian Sid, with my own kernel) I have noticed that I am not longer getting ac_adapter events. This implies to me that it's something Ubuntu is doing, although I haven't nailed down what.
Alot of these problems with batteries and other ACPI related issues comes from buggy DSDT's. This is the ACPI description table contained in the bios. I had similar problems and had to fix my buggy DSDT and am now loading my new fixed version on bootup. If you want more details, google acpi4linux and read about the DSDT's, you may even find a fixed one for your laptop. If not, email me and I may be able to help you out, since I am quite familiar with the Intel ACPI spec. mszilveszter at gmail dot com Cheers,
I actually worked out what the problem in Ubuntu is and have informed MJG. Shutting down ACPId and running `cat /proc/acpi/events` showed that ac_adapter events were indeed coming from the kernel, but acpi_listen showed they were not being forwarded from acpid in a timely fashion (or at all). The problem comes from the script (in Ubuntu's case) /etc/acpi/power.sh, the event won't be relayed until the script is complete, and I think relaying is also dependant on the error code returned by the script (not too sure on this though). Wrapping the entire script in: power_script() { # script here } power_script & causes events to come through from ACPId in a timely fashion making the battery applet work and others work nicely again. We should not poll ac state with every battery event (if it doesn't work, fix your DSDT as Mark S indicated) and as an aside, Ubuntu should not be running the power configuring code with every battery event since it takes forever to execute anyway and is constantly blocking up events from being relayed to other clients.
Marking this at NOTGNOME.
*** Bug 164780 has been marked as a duplicate of this bug. ***