Bug 301033

I forgot to say that everything's was fine with the first set of tarballs.

I confirm this is happening for me too on KDE Development Platform: 4.8.80 (4.8.80)

Arch Linux kde unstable binaries 4.8.80-1, I'm affected by this too.
Thanks Andrea Scarpino for build those for us to find bugs and thanks to KDE foks !

Confirmed by several users.

Can you look in plasmaengineexplorer, select "powermanagement"

expand everything and take a screenshot.

Created attachment 71524 [details]
powermanagement in plasmaengineexplorer

$ upower -d
Device: /org/freedesktop/UPower/devices/line_power_AC
  native-path:          /sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/AC
  power supply:         no
  updated:              Sat Jun  2 18:36:32 2012 (259 seconds ago)
  has history:          no
  has statistics:       no
  line-power
    online:             yes

Device: /org/freedesktop/UPower/devices/battery_BAT0
  native-path:          /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/BAT0
  model:                DELL TY3P409
  serial:               24710
  power supply:         no
  updated:              Sat Jun  2 18:40:37 2012 (14 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               fully-charged
    energy:              57.4912 Wh
    energy-empty:        0 Wh
    energy-full:         57.4912 Wh
    energy-full-design:  57.6239 Wh
    energy-rate:         0.011056 W
    voltage:             12.395 V
    percentage:          100%
    capacity:            80.1228%
    technology:          lithium-ion

Daemon:
  daemon-version:  0.9.16
  can-suspend:     yes
  can-hibernate    yes
  on-battery:      no
  on-low-battery:  no
  lid-is-closed:   no
  lid-is-present:  yes
  is-docked:       no

Screenshot shows problem exists in either powerdevil or dataengine _not_ the widget.

Have you rebooted since installing 4.9?

Next thing to test (to trace where the error is)
output of :
solid-hardware details /org/freedesktop/UPower/devices/battery_BAT0

if that's correct, it must be the dataengine.

$ solid-hardware details /org/freedesktop/UPower/devices/battery_BAT0
udi = '/org/freedesktop/UPower/devices/battery_BAT0'
  parent = '/org/freedesktop/UPower'  (string)
  vendor = 'Hewlett-Packard'  (string)
  product = 'Primary'  (string)
  description = 'Lithium Ion Battery'  (string)
  Battery.plugged = true  (bool)
  Battery.type = 'UnknownBattery'  (0x0)  (enum)
  Battery.chargePercent = 97  (0x61)  (int)
  Battery.rechargeable = true  (bool)
  Battery.chargeState = 'NoCharge'  (0x0)  (enum)

I have the same results as others with upower -d and plasmaengineexplorer. I have rebooted twice since installing the update.

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

Not yet sure if the (new QML) battery widget is to blame, or the solid power management, but I just had a sudden power off. I drained the battery because the notifications where missing. Raising severity.

Marking it as a regression in 4.9beta.

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

I added Lukas Tinkl to the email list, as that looking at the output mentioned in Comment #7 then his commit from the 29th May in kdelibs (to fix bug 300787) might have caused this issue. 

If I understand the code correctly, then he is validating if the Primary battery is a power supply. Looking at the output in Comment #7, then the primary battery there is indicated that it isn't a power supply. 

At the moment I am rebuilding kdelibs with his patch reverted to see if this would indeed resolve the current battery issue.

power supply:         no 

... is the problem (with recent kernels and upower 0.9.16)

I'm debugging this with upower's author as I'm writing this :)

Could your initial patch be reverted ?  I am asking as that this not only affects KDE 4.9 but also KDE 4.8.4 release as that they both share the same KDELIBS version.

KDE 4.8.4 is about to be released and this would be a very strong regression, that will never be fixed anymore for the 4.8.x series. 

If reverted, we should inform the release team to create a new tarball for kdelibs.

Lukas you need to be quick if this patch needs to be in 4.8. Another patch is pending for kdelibs so the release is delayed and there's a good chance kdelibs can be retagged. Can you fix it today and notify the release-team immediately with a link to the patch please?

Hmm, looking at the debug output in comment #9, the battery is correctly marked as Primary, which is sufficient in this case. Furthermore, I don't see this problem in KDE 4.8, so it must be a regression in the new QML applet in KDE 4.9.

The power-supply upower field is used only when calculating the remaining time and it won't be reverted, newer kernels report more battery types (mouse, keyboard, BT, etc.) so it was added not to confuse the battery applet with external batteries, irrelevant to the PC itself.

Hrm... looking at it again, it probably causes more problems than it gains. Better display more batteries than none I guess, I will revert and notify kde packagers

Lukas, 

It seems the retag for kdelibs 4.8.4 will be done sometime today. So your revert and notification should be done quickly to ensure we have the right situation.

Git commit 7f8c750541790de5a380409466cf07cfe19c3651 by Lukas Tinkl.
Committed on 06/06/2012 at 15:47.
Pushed by lukas into branch 'KDE/4.8'.

Revert "don't consider external batteries (mice, keyboard, BT) as primary"

This reverts commit d1661d1638851fd950c5926fb2040ea2abe2a8f0.

This causes more trouble than expected, newer kernels/upower contain a bug that (in my case
and many others) marks ALL batteries as non-powersupply.
Related: bug 300787

M  +2    -5    solid/solid/backends/upower/upowerbattery.cpp

http://commits.kde.org/kdelibs/7f8c750541790de5a380409466cf07cfe19c3651

After recompiling kdelibs I can confirm that it works, thanks a lot for the quick "fix" and your great work. 

Kind regards

The temporary fix works for me too.

However, I'm not sure we should consider this as fixed as related to Lukas comment.

Git commit 240411008dce4557d9dd536cc517471394219a80 by Dirk Mueller, on behalf of Lukas Tinkl.
Committed on 06/06/2012 at 15:47.
Pushed by mueller into branch 'KDE/4.8.x'.

Revert "don't consider external batteries (mice, keyboard, BT) as primary"

This reverts commit d1661d1638851fd950c5926fb2040ea2abe2a8f0.

This causes more trouble than expected, newer kernels/upower contain a bug that (in my case
and many others) marks ALL batteries as non-powersupply.
Related: bug 300787

M  +2    -5    solid/solid/backends/upower/upowerbattery.cpp

http://commits.kde.org/kdelibs/240411008dce4557d9dd536cc517471394219a80

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

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

I've got similar issue:
My notebook have 2 batteries, but kde 4.9 beta1 and beta2 shows that only one is present (and tries to hibernate notebook when I've got almost >50% capacity of 2-nd, because primary discharged). Even with "Show the state for each battery present".

upower -d shows both batteries.

Same issue here. Also checked my battery with upower -d, it's actually present. Other DE's behave well. So it's a KDE issue. Using 4.9.2 from Arch Linux off. repos.

Reopening based on comments #28 and #29

Jason and Vladimir, what is your kernel and upower version?

Kernel 3.4 and 3.5. Haven't tested on 3.6 yet. This bug doesn't appears in KDE 4.8 (haven't tested latest 4.8 release though), but present on KDE 4.9.x.

Additionaly, powerdevil sometimes fails to detect if AC Charge is pluged in (or may lose it after batteries fully charged), console tools such as upower and acpitool detects everything normally.

Notebook is Fujitsu-Siemens P771 with 2 Batteries. upower -d says (my nb is at home, so lid is closed, it's ok):
Device: /org/freedesktop/UPower/devices/line_power_AC
  native-path:          /sys/devices/LNXSYSTM:00/device:00/ACPI0003:00/power_supply/AC
  power supply:         yes
  updated:              Thu Oct 11 10:18:27 2012 (30294 seconds ago)
  has history:          no
  has statistics:       no
  line-power
    online:             yes

Device: /org/freedesktop/UPower/devices/battery_CMB1
  native-path:          /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:00/power_supply/CMB1
  vendor:               Fujitsu
  model:                CP483691-01
  serial:               01A-Z110610001548Z
  power supply:         yes
  updated:              Thu Oct 11 18:43:02 2012 (19 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               fully-charged
    energy:              57.024 Wh
    energy-empty:        0 Wh
    energy-full:         59.4 Wh
    energy-full-design:  66.96 Wh
    energy-rate:         3.6288 W
    voltage:             12.259 V
    percentage:          96%
    capacity:            88.7097%
    technology:          lithium-ion

Device: /org/freedesktop/UPower/devices/battery_CMB2
  native-path:          /sys/devices/LNXSYSTM:00/device:00/PNP0C0A:01/power_supply/CMB2
  vendor:               Fujitsu
  model:                CP384580-01
  serial:               03A-T101004000028T
  power supply:         yes
  updated:              Thu Oct 11 18:43:02 2012 (19 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               fully-charged
    energy:              24.84 Wh
    energy-empty:        0 Wh
    energy-full:         27 Wh
    energy-full-design:  27 Wh
    energy-rate:         1.944 W
    voltage:             12.232 V
    percentage:          92%
    capacity:            100%
    technology:          lithium-ion

Daemon:
  daemon-version:  0.9.18
  can-suspend:     no
  can-hibernate    no
  on-battery:      no
  on-low-battery:  no
  lid-is-closed:   yes
  lid-is-present:  yes
  is-docked:       no

(In reply to comment #31)
> Jason and Vladimir, what is your kernel and upower version?

The kernel was 3.5.4 and upower  0.9.18

But anyway, the issue was surprisingly resolved after removing ~/.kde4 folder.

The issue suddenly reappeared, I guess after kernel update.

@Jason: hmm, that's strange. I was struck by the issue originaly, but it was resolved and did not reappear now here (kernel 3.6.6, archlinux)

@Marek Otahal
Yup also using Arch's 3.6.6 now, though issue appeared again not long before kernel upgrade to 3.6.6, but after upgrade to one of previous kernels, 3.6.something. Again, deleting .kde4 folder does fix it. Which, of course, makes me go to settings window again. :-D. But, obviously, the problem may still be not solved, or already is, I don't know.

@Jason
Could you try to narrow down your solution to which config file actually is the culprit here as removing the whole .kde directory is too radical for a workaround ;).

@Bogdan Mihaila
I'm just no expert in KDE architecture. :)
Well, now I tried to remove ~/.kde4/share/config/powermanagementprofilesrc and powerdevilrc. But that didn't help. Could you, please, specify some other options if there are?

@Jason
I'm no expert either but by doing a grep for "power" and "battery" in the .kde/share/config folder on my system one interesting config file seem to be: "plasma-desktop-appletsrc".

But I guess it is nor really so much about the config files. Did you restart plasma or logged in again or logged into a fresh user profile or how did you try the above? As far as I can see if you restart plasma then the battery is present again, so it might not have so much to do with the config. Or is it now working always after the fresh config?

Ok, I did some experiments and narrowed down the problem a bit. My system is as follows:
KDE 4.9.3 and Kernel 3.5.0 (more info on request).

By using a quickly hacked down test plasmoid in python and the plasmaengineexplorer I realized that the powermanagement engine with the data source "Battery" (as used by the battery QML plasmoid) does not change the value for the key "Has Battery" when plugging/unplugging the battery but remains at the last state. The key "Sources" on the other side is updated correctly and has "Battery0" or nothing if the battery is removed. If restarting the plasmoid and thus reconnecting to the engine everything seems to be updated again to the correct state.

Because of that the QML battery plasmoid does not get updated when plugging/unplugging the battery and gets stuck. As far as I could see it queries the mentioned field with 
"51: property bool hasBattery: pmSource.data["Battery"]["Has Battery"]"
to know if there is a battery present or not. As this value never changes after the start the battery plasmoid status won't change either.

Any hints on how to dig deeper and find the cause?

On a second note, the plasmoid also queries properties on "Battery0", e.g:
52: property int percent: pmSource.data["Battery0"]["Percent"]
even though the battery might not be present (meaning that the data source "Battery0" won't exist). This leads to the errors reported by plasma in the console like:
file:///usr/share/kde4/apps/plasma/plasmoids/battery/contents/ui/batterymonitor.qml:52: TypeError: Result of expression 'pmSource.data["Battery0"]' [undefined] is not an object. This queries should be guarded and only executed if a battery is present.

@Bogdan Mihaila
Well, back then I just removed .kde4 folder being logged in, logged out and everything was fine again.
You were right about plasma-desktop-appletsrc. :) This time I just removed it and did "killall plasma-desktop && plasma-desktop" (again, being logged in) and battery applet is here again. :P
Great work and thank you!

@Jason

Now we would need to find out if it is about removing the config file or only about restarting plasma. So could you try a couple of things:
If you restart plasma without removing the config file is the battery back?
If you quit plasma with "kquitapp" does it make any difference to "killall"? The first one makes plasma write things back to files before quitting.
Could you try in a console: "plasmoidviewer battery" or "plasma-windowed battey"  depending on which is installed on your system to test the battery applet. Start the applet that way then add/remove the battery and see if the applet reflects the changes. If not then close the applet and restart it with the same command and see if it now reflects the battery state.
On my system the applet just needs restarting.

Thx 
Bogdan

Yup, if you restart the applet, it "reloads" the dataengine and the problem is solved but this is really a workaround only, not the correct fix. Working on it...

Created attachment 75286 [details]
Tentative patch correcting source connects/disconnects

This patch should fix tracking the state of HasBattery and AC adapter

I cannot reproduce myself but could you please the above patch? Thanks

@Bogdan MIhaila
Hello, you are a master of debugging. :)
So, I started plasmoidviewer battery with terminal, removed battery, plasmoid still indicated battery is present. Restarted plasmoid, now it did show that there's no battery.
As regards the difference between "killall" and kquitapp, to me it seems, there's no any. Again, removed battery, there was no indication at panel bat applet that I removed it, did "kquitapp plasma-desktop", started plasma-desktop again without battery, inserted it back, still no indication that's it back. Restarted, things are back again. I didn't remove config file while doing all this - as you proposed. -)

@Lukáš Tinkl 
Thanks a lot for the patch! But how do I install it?

@Bogdan Mihaila
But again, I would like to add that despite it all seeming it has nothing to do with the config file, rather with restarting plasma - previously, when the problem appeared for the first time and later again, simple rebooting the computer (and thus, restarting plasma), didn't do the trick.
So let's see if the patch will do the trick in preventing such in the future. I mean, what if it would happen with someone else.

Created attachment 75313 [details]
Workaround for the battery state bug.

@Lukáš

I tried your patch but it does not work, The lines you changed do not modify the behaviour of the plasmoid as the problem lies somewhere else. Nevertheless, the patch improves the code so should be merged in. 
The problem as already mentioned in my last post is that the data engine for the source "Battery" does not update the field "Has Battery" to the current battery state but stays in true/false as it was when first connected to the data engine.
I attached a patch that fixes the issue but I think it should only be seen as a workaround and the data engine needs to be fixed.

@Jason
Could you try the patch and tell if it also works for you? You can apply it by copying it to the "/usr/share/kde4/apps/plasma/plasmoids/battery/contents/ui" directory and doing a "patch < battery_plasmoid.patch" as root or with sudo as the files there belong to root,

@Bogdan MIhaila
Thing is, there's no "/usr/share/kde4/apps/plasma/plasmoids/battery/contents/ui". My /usr/share/kde4 only has 2 folders - those are "services" and "servicetypes". I guess, that's because locations are different now or something - I use Arch Linux packages, probably need to learn how to use ABS (Arch Build System) first, so that i could package your patch and see if it works. O:-) But wait, i'll try to find where the stuff is located. Sorry for late response.

@Bogdan Mihailo
Ok, found the location. Question - how do I then remove the patch?

@Jason
"patch -R < battery_plasmoid.patch" does the trick of reversing the patch but you could also do a backup of the batterymonitor.qml file before applying the patch (backups are always good ;) ).
Tell me if after applying the patch and restarting plasma you can insert/remove your battery with the plasmoid reacting to the changes.

Bogdan, your patch has fixed the issue with the battery state bug in my pc but there's still a small issue. I'm using kdeplasma-addons 4.9.3-1.

I've applied the patch proposed by Lukáš and it didn't solve the problem. Then I applied the Bogdan's patch and there's a little bug but it's working. When I turn on the pc, the first state of the plasmoid is that the pc is "pluged in to AC and the battery is present with 0% (charging)" although I'm not using the battery.
Then I connect the battery and the state doesn't change. After that, I disconnect the battery and the state is "pluged in to AC with no battery". At this moment, the plasmoid start to behave as expected. If I connect the battey, the state is "pluged in to AC with battery present" and indicates the correct amount of charge of the battery.

@simunic
Hi. Just realized the same problem today, never tried it in that combination of events before. Will look as how to make it behave right from the start without the remove/insert necessity.

Git commit 0e2b6219e3a57386cba64d7aae443106994e2ff2 by Lukáš Tinkl.
Committed on 21/11/2012 at 16:05.
Pushed by lukas into branch 'KDE/4.9'.

reflect whether the system has/doesn't have battery plugged in

fixes #301033 - Battery Not present
FIXED-IN: 4.9.4

M  +4    -2    plasma/generic/dataengines/powermanagement/powermanagementengine.cpp

http://commits.kde.org/kde-workspace/0e2b6219e3a57386cba64d7aae443106994e2ff2

Git commit e5e90931a7a8475c0830fe40c79586e4f2ce9413 by Lukáš Tinkl.
Committed on 21/11/2012 at 16:05.
Pushed by lukas into branch 'master'.

reflect whether the system has/doesn't have battery plugged in

fixes #301033 - Battery Not present
FIXED-IN: 4.9.4

M  +4    -2    plasma/generic/dataengines/powermanagement/powermanagementengine.cpp

http://commits.kde.org/kde-workspace/e5e90931a7a8475c0830fe40c79586e4f2ce9413

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

Works perfectly, thx!