battery widget does not show current status as it changes

When removing the battery (e.g. after fully charged), the applet still says that battery is present. Restarting plasma-desktop is needed to correct the display.

The reverse is also true and worse. When I had plasma started without battery, inserting it does not update the display, so I cannot see battery state until I kill plasma again.

I assume you did check how upower and solid report this? And is this a new 4.9beta regression, or was it already present in 4.8?

Hi, I try KDE4,9 and I fond it cannot read my battery state. It can read it after I login to KDE and can read (un)plugging AC, but cannot read the change of battery state.

It seems the detection just stops to work after some time....
output from "qdbus --system org.freedesktop.UPower /org/freedesktop/UPower/devices/battery_BAT0 org.freedesktop.UPower.Device.Percentage" when the detection is OK:
97.7599738391105

And the detections stops just right in the moment I plugin AC power.:

96.3374754741661... etc.

stats in /proc/acpi/battery/BAT0/state are changing...:
tomas@tom-MacBookAir:~/Dokumenty$ cat /proc/acpi/battery/BAT0/state
present: yes
capacity state: ok
charging state: discharging
present rate: 28787 mW
remaining capacity: 58760 mWh
present voltage: 8091 mV
tomas@tom-MacBookAir:~/Dokumenty$ cat /proc/acpi/battery/BAT0/state
present: yes
capacity state: ok
charging state: charged
present rate: 0 mW
remaining capacity: 58700 mWh
present voltage: 8252 mV

I can confirm this in kubuntu quantal using alpha 3 candidate images

reported as https://bugs.launchpad.net/ubuntu/+source/kdebase-workspace/+bug/1028591

*** This bug has been marked as a duplicate of bug 302310 ***

*** Bug 303812 has been marked as a duplicate of this bug. ***

(In reply to comment #1)
> is this a new
> 4.9beta regression, or was it already present in 4.8?

Just upgraded to RC2 from 4.8.4: Same here. It's a new regression.

Could this be a Solid bug and not the Plasmoid's?

This is the plasmoid's bug.

The bug has been fixed with commit 79fcc16f.
https://projects.kde.org/projects/kde/kde-workspace/repository/diff?rev=79fcc16f1396c6e424a3f8f932d45885a9b0f9b9&rev_to=6894e736d5c043dfee6fcd5e13884ab1925a2d09

Not fixed, at least not fully. I used my laptop without battery, then put it into standby, inserted the battery, unplugged the power cord, and switched my laptop on. Plasmaapplet claims that no battery is present (no cord is correctly detected).

Please try KDE 4.10 rc 3

https://projects.kde.org/projects/kde/kde-workspace/repository/diff?rev=70ed17ef99dd33adda271ebc338d82039b191caf

I think this should fix it.

https://git.reviewboard.kde.org/r/108355/

It still does not work correctly on today's master. Starting the computer without a battery, I correctly see the red X on the battery in systray. Inserting the battery, however, does not remove this X indicator. I have to restart plasma-desktop, to get it to recognize the battery.

*** Bug 312227 has been marked as a duplicate of this bug. ***

Hello,
I'm a also a user of plasma desktop version 4.10.
I found out that removing the battery and reinserting it while the user is logged in actually works as expected (shows that the battery was removed and reinserted).
the problem appears when logging in without the battery (with AC plugged only) and then trying to reinsert the battery back to the computer actually does NOTHING to the battery monitor and it doesn't recognize that the battery was inserted - though the computer uses the battery as usual (when unplugging AC).
As a result the system doesn't warn about critical battery charge and, well, after a while the whole work will be lost because of sudden shutdown.

I tried working this bug around by inserting the battery, logging out, logging in again, and here it is the battery monitor is back and fully functional.

Hope that helps solving the bug ;-)
And btw I've worked with lower versions of KDE and didn't have that bug...
Thnx

*** Bug 315483 has been marked as a duplicate of this bug. ***

*** Bug 317196 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of bug 316213 ***