Version: unspecified (using KDE 4.6.1) OS: Linux acpitool -B will show the correct battery status, but the battery monitor applet shows zero battery after resuming. Restarting kdm/laptop fixes it. Can provide more debugging info if someone can guide me. Reproducible: Sometimes Steps to Reproduce: suspend, resume, check battery applet Actual Results: battery applet shows zero battery
Same problem here. Lenovo Thinkpad T510, Arch Linux x86_64, KDE 4.6.1. Sometimes after resume battery applet shows a very little value (~9%). acpitool -b shows right value: Battery #1 : discharging, 86.46%, 01:46:37
I have a thinkpad T410, perhaps lenovo specific ? I've also seen it intermittently fix itself after a couple of resumes.
> I've also seen it intermittently fix itself after a couple of resumes. Me too.
(In reply to comment #2) > I have a thinkpad T410, perhaps lenovo specific ? I've also seen it > intermittently fix itself after a couple of resumes. I can also confirm this problem with Thinkpad T410. acpi -b returns: 84% KDE claims: 10% (charged) Version: KDE 4.6.1 OS: ArchLinux x86_64
Created attachment 58480 [details] battery lever faulty
I can confirm same bug on ThinkPad T410. Always happens after resume from standby. Sometimes it fixes magically, but in most cases, it looks like KDE is trying to manually calculate remaining battery, and then fails. On the other hand - remaining TIME is displayed quite accurately. Some times I get e.g. Remaining 7%; 3:15 hours. IT should be more like 70%
I can confirm same bug on ThinkPad T410. Always happens after resume from standby. Sometimes it fixes magically, but in most cases, it looks like KDE is trying to manually calculate remaining battery, and then fails. On the other hand - remaining TIME is displayed quite accurately. Some times I get e.g. Remaining 7%; 3:15 hours. IT should be more like 70%. Cant there be a rounding mistake?
One more thing - the remaining time in plasmoid and acpi is relatively close, but definitively not the same. Where does KDE read battery info from? linux-ia7r:/home/lukas # acpi Battery 0: Discharging, 98%, 02:21:33 remaining KDE 10% 2:17
Same here with a ThinkPad T410s after some suspend/resume cycles. The problem seems to be that /proc/acpi/battery/BAT0/state switches from reporting mWh to mAh! Then, all values are 10x smaller than before and, thus, 10% really means 100%.
BTW, /sys/class/power_supply/BAT0/energy_now constantly reports µAh.
That might be distro specific. I have current_now & charge_now, no energy_now. In the meantime, could we get the cancel button that was there previously with the 30 seconds warning back. I end up having to run to the power outlet as cancel is no longer an option, even though the battery has charge.
@Anish: You are right. Do these files constantly report µAh for you? @All: A much more serious problem arises, if /proc/acpi/battery/BAT0/state switches from reporting mAh to mWh, i.e., the other way round. Then, the applet always thinks that the battery is full, even if it is almost empty. Thus, there is finally no automatic shutdown!
Well, cant we use data from /sys/class/power_supply/BAT0/, so REAL_CHARGE = charge_now/charge_full * 100; ? From what I have tested, it always showed right values. If some hardware/distros does not support this, just fall back to the current system.
KDE 4.7.0 Problem seems to be fixed for me
It was mostly like an upstream bug - recent versions of UPower should have fixed that.