Bug 422111 - Battery applet not showing up in tray.
Summary: Battery applet not showing up in tray.
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Battery Monitor (show other bugs)
Version: 5.23.3
Platform: unspecified Linux
: VHI normal
Target Milestone: 1.0
Assignee: Kai Uwe Broulik
URL:
Keywords: regression
: 350365 421779 422678 423347 428896 429703 430044 436911 442670 444528 445911 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-05-26 18:38 UTC by petrk
Modified: 2022-04-20 15:40 UTC (History)
47 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.24.5


Attachments
~/.config/plasma-org.kde.plasma.desktop-appletsrc (8.39 KB, text/plain)
2020-06-11 17:02 UTC, petrk
Details
Screenshot with info center and battery applet (621.59 KB, image/png)
2020-06-20 06:26 UTC, Nishith Khanna
Details
Screenshot with battery icon missing. (364.54 KB, image/png)
2020-06-22 12:36 UTC, Tony
Details
Plasma applets confi file. (6.17 KB, text/plain)
2020-06-22 12:42 UTC, Tony
Details
org.kde.powerdevil debug log when battery applet does NOT appear (1.90 KB, text/x-log)
2021-07-15 22:56 UTC, Sam Edwards
Details
org.kde.powerdevil debug log when battery applet DOES appear (2.32 KB, text/x-log)
2021-07-15 23:02 UTC, Sam Edwards
Details

Note You need to log in before you can comment on or make changes to this bug.
Description petrk 2020-05-26 18:38:11 UTC
SUMMARY

It seems that in 5.18.90 battery is not being detected in my laptop. Kinfocenter shows battery stats just fine.

STEPS TO REPRODUCE
1. Upgrade to 5.18.90
2. Look at system tray
3. No battery icon

OBSERVED RESULT

No battery icon.

EXPECTED RESULT

Battery icon showing current charge percentage.

Operating System: Arch Linux 
KDE Plasma Version: 5.18.90
KDE Frameworks Version: 5.70.0
Qt Version: 5.15.0
Kernel Version: 5.6.14-zen1-1-zen
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-3720QM CPU @ 2.60GHz
Memory: 15.4 GiB RAM
Graphics Processor: Mesa DRI Intel® HD Graphics 4000
Comment 1 petrk 2020-06-09 21:43:26 UTC
Still an issue after 5.19 shipped on arch.
Comment 2 David Edmundson 2020-06-10 21:03:31 UTC
Can I have someone's ~/.config/plasma-org.kde.plasma.desktop-appletsrc please
Comment 3 petrk 2020-06-11 17:02:33 UTC
Created attachment 129238 [details]
~/.config/plasma-org.kde.plasma.desktop-appletsrc

Requested config file attached.
Comment 5 petrk 2020-06-11 22:02:20 UTC
Patch above fixes it for me, battery applet is back, thanks.
I assume it's going to land in 5.19.1?
Comment 6 Nate Graham 2020-06-12 16:41:08 UTC
*** Bug 422678 has been marked as a duplicate of this bug. ***
Comment 7 David Edmundson 2020-06-15 22:11:38 UTC
Huh, somehow my landed commit message is broken which is why this didn't autoclose
Comment 8 Nate Graham 2020-06-18 18:51:16 UTC
*** Bug 421779 has been marked as a duplicate of this bug. ***
Comment 9 Nishith Khanna 2020-06-20 06:14:56 UTC
Hi, I updated to 5.19.1 and this bug is still happening. When starting my laptop or waking it up from sleep randomly makes applet to dissappear. When I add the applet manually it says no batteries available.
Below is the info that I copied from info center.

Operating System: Manjaro Linux
KDE Plasma Version: 5.19.1
KDE Frameworks Version: 5.71.0
Qt Version: 5.15.0
Kernel Version: 5.7.4-1-MANJARO
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-6200U CPU @ 2.30GHz
Memory: 11.6 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 520
Comment 10 Nishith Khanna 2020-06-20 06:26:19 UTC
Created attachment 129538 [details]
Screenshot with info center and battery applet
Comment 11 Nate Graham 2020-06-20 17:29:45 UTC
That looks like a slightly different issue. Can you file a new bug report please? Thanks!
Comment 12 Tony 2020-06-22 12:34:30 UTC
Unfortunately, this bug is still here. 
Since the update to 5.19.1 this is the second time it appears, now i have documented it. An attachment has been added. 

Operating system: KDE neon 5.19
KDE Plasma version: 5.19.1
KDE Frameworks version: 5.71.0
Qt version: 5.14.2
Kernel: 5.3.0-59-generic
OS type: 64-bit
Processors: 4 × Intel® Core™ i5-3320M CPU @ 2.60GHz
Memory: 7,6 GiB di RAM
Graphic processor: Mesa DRI Intel® Ivybridge Mobile
Comment 13 Tony 2020-06-22 12:36:01 UTC
Created attachment 129580 [details]
Screenshot with battery icon missing.
Comment 14 Tony 2020-06-22 12:42:55 UTC
Created attachment 129581 [details]
Plasma applets confi file.
Comment 15 Nate Graham 2020-06-22 18:07:44 UTC
*** Bug 423347 has been marked as a duplicate of this bug. ***
Comment 16 Nate Graham 2020-06-22 18:08:12 UTC
Re-opening as we're getting reports from people using 5.19.1 that it's still not fixed. :(
Comment 17 Andrew Brouwers 2020-06-24 00:15:55 UTC
Happening for me on a fresh 5.19.2 config.
Comment 18 devnulll 2020-06-28 13:35:00 UTC
I can confirm it, not yet fixed, despite choosing "always shown" in the tray settings. Plasma wayland session.

------------------------------
Operating System: Arch Linux
KDE Plasma Version: 5.19.2
KDE Frameworks Version: 5.71.0
Qt Version: 5.15.0
Kernel Version: 5.6.19.a-1-hardened
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-6200U CPU @ 2.30GHz
Memory: 7,6 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 520
Comment 19 devnulll 2020-06-28 15:05:16 UTC
Update: After logging out and logging in, the icon is shown... But still, it didn't show up when I selected "Always shown".
Comment 20 David Edmundson 2020-06-29 14:40:55 UTC
Can I see the output of:

qdbus org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames

from someone experiencing this with new Plasma
Comment 21 devnulll 2020-06-29 14:49:46 UTC
(In reply to David Edmundson from comment #20)
> Can I see the output of:
> 
> qdbus org.freedesktop.DBus /org/freedesktop/DBus
> org.freedesktop.DBus.ListNames
> 
> from someone experiencing this with new Plasma

org.freedesktop.DBus
org.freedesktop.Notifications
org.freedesktop.Akonadi.Resource.akonadi_birthdays_resource
org.freedesktop.PowerManagement
:1.8
org.kde.kappmenu
:1.9
org.kde.kaccess
org.freedesktop.Akonadi.Agent.akonadi_imap_resource_0
org.freedesktop.Akonadi.Agent.akonadi_contacts_resource_0
org.kde.korgac
org.freedesktop.Akonadi.Agent.akonadi_maildispatcher_agent
org.kde.pim.TransportManager
org.kde.kdeconnect
org.freedesktop.Akonadi.Agent.akonadi_unifiedmailbox_agent
org.freedesktop.Akonadi.Agent.akonadi_maildir_resource_0
org.kde.dolphin-6080
org.kde.krunner
org.kio5.kio_http_cache_cleaner
:1.60
org.freedesktop.Akonadi.Resource.akonadi_unifiedmailbox_agent
org.freedesktop.Akonadi.Resource.akonadi_maildir_resource_0
:1.40
org.a11y.Bus
org.kde.StatusNotifierHost-643
:1.41
org.kde.GtkConfig
:1.42
org.freedesktop.Akonadi.Agent.akonadi_ical_resource_0
org.freedesktop.Akonadi
:1.20
org.kde.kmail
:1.43
org.kde.klauncher5
:1.21
:1.152
:1.44
:1.22
org.kde.konsole-16634
:1.45
:1.23
org.kde.kscreen.osdService
org.freedesktop.Akonadi.Agent.akonadi_mailfilter_agent
:1.46
org.kde.Solid.PowerManagement
org.freedesktop.PowerManagement.Inhibit
:1.47
:1.25
org.freedesktop.Akonadi.Agent.akonadi_archivemail_agent
:1.48
:1.26
org.kde.kmail2
org.kde.plasma.browser_integration
org.kde.screensaver
org.kde.KWin
org.freedesktop.Akonadi.Agent.akonadi_akonotes_resource_0
:1.29
ca.desrt.dconf
org.freedesktop.Akonadi.Agent.akonadi_newmailnotifier_agent
org.freedesktop.Akonadi.NewMailNotifierAgent
org.freedesktop.ScreenSaver
org.freedesktop.Akonadi.Resource.akonadi_imap_resource_0
org.freedesktop.Akonadi.Resource.akonadi_contacts_resource_0
org.kde.plasmashell
org.kde.plasmanetworkmanagement
org.freedesktop.Akonadi.Control
local.org_kde_powerdevil
org.freedesktop.Akonadi.Agent.akonadi_sendlater_agent
org.kde.kglobalaccel
org.freedesktop.FileManager1
org.freedesktop.Akonadi.Agent.akonadi_followupreminder_agent
org.kde.kdeconnect.daemon
org.kde.kwalletd5
org.freedesktop.Akonadi.Janitor
org.kde.polkit-kde-authentication-agent-1
org.freedesktop.Akonadi.MailDispatcherAgent
com.canonical.Unity
org.freedesktop.Akonadi.Agent.akonadi_migration_agent
org.freedesktop.Akonadi.Resource.akonadi_ical_resource_0
org.kde.kded5
org.mozilla.firefox.ZGVmYXVsdC1yZWxlYXNl
:1.50
org.kde.ActivityManager
:1.51
:1.30
:1.53
:1.31
org.freedesktop.Akonadi.Control.lock
:1.54
org.kde.kuiserver
:1.10
:1.55
:1.33
:1.11
:1.34
:1.12
org.kde.StatusNotifierWatcher
:1.165
:1.57
org.kde.JobViewServer
:1.35
org.freedesktop.Akonadi.Resource.akonadi_akonotes_resource_0
:1.13
:1.58
org.freedesktop.Akonadi.Agent.akonadi_indexing_agent
:1.36
:1.1
:1.14
:1.167
org.freedesktop.Akonadi.Agent.akonadi_birthdays_resource
:1.37
:1.15
:1.38
:1.3
org.kde.ksmserver
:1.147
:1.39
org.kde.kcookiejar5
:1.17
org.kde.Solid.PowerManagement.PolicyAgent
:1.18
:1.6
:1.19
Comment 22 Andrew Brouwers 2020-06-29 15:49:23 UTC
I just restarted plasma, and successfully had it not appear (running 5.19.2)

$ qdbus org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames
org.freedesktop.DBus
org.freedesktop.Notifications
:1.227
org.freedesktop.PowerManagement
org.kde.kappmenu
org.kde.kaccess
org.freedesktop.systemd1
org.pulseaudio.Server
org.kde.KScreen
:1.250
org.kde.klauncher5
:1.251
:1.23
org.kde.kscreen.osdService
:1.253
:1.231
org.freedesktop.PowerManagement.Inhibit
org.kde.Solid.PowerManagement
:1.254
:1.233
:1.234
:1.235
org.kde.KWin
org.kde.screensaver
ca.desrt.dconf
:1.236
:1.237
:1.238
org.freedesktop.ScreenSaver
:1.239
org.kde.plasmashell
org.kde.plasmanetworkmanagement
org.kde.konsole-51945
local.org_kde_powerdevil
org.kde.kglobalaccel
org.kde.kwalletd5
org.PulseAudio1
org.kde.polkit-kde-authentication-agent-1
com.canonical.Unity
org.kde.kded5
org.kde.ActivityManager
org.kde.keyboard
org.kde.kuiserver
:1.240
org.kde.StatusNotifierHost-51566
org.kde.StatusNotifierWatcher
:1.241
org.kde.JobViewServer
:1.0
:1.242
:1.243
:1.244
org.kde.ksmserver
org.kde.kcookiejar5
:1.246
org.kde.Solid.PowerManagement.PolicyAgent
:1.247
:1.248
Comment 23 Andrew Brouwers 2020-06-29 15:50:48 UTC
Then, after a kquitapp & kstart plasmashell, (which makes it appear pretty consistently):

$ qdbus org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames
org.freedesktop.DBus
org.freedesktop.Notifications
:1.227
org.freedesktop.PowerManagement
org.kde.kappmenu
org.kde.kaccess
org.freedesktop.systemd1
org.pulseaudio.Server
org.kde.KScreen
:1.250
org.kde.klauncher5
:1.251
:1.23
org.kde.kscreen.osdService
:1.253
:1.231
org.freedesktop.PowerManagement.Inhibit
org.kde.Solid.PowerManagement
:1.233
org.kde.StatusNotifierHost-51999
:1.234
:1.257
:1.235
org.kde.KWin
org.kde.screensaver
:1.258
ca.desrt.dconf
:1.236
:1.237
:1.238
org.freedesktop.ScreenSaver
:1.239
org.kde.plasmashell
org.kde.plasmanetworkmanagement
org.kde.konsole-51945
local.org_kde_powerdevil
org.kde.kglobalaccel
org.kde.kwalletd5
org.PulseAudio1
org.kde.polkit-kde-authentication-agent-1
com.canonical.Unity
org.kde.kded5
org.kde.ActivityManager
org.kde.keyboard
:1.260
org.kde.kuiserver
:1.240
org.kde.StatusNotifierWatcher
:1.241
org.kde.JobViewServer
:1.0
:1.242
:1.244
org.kde.ksmserver
org.kde.kcookiejar5
:1.246
org.kde.Solid.PowerManagement.PolicyAgent
:1.247
:1.248
Comment 24 Christoph Feck 2020-07-13 12:14:58 UTC
New information was added with recent comments; chaning status for inspection.
Comment 25 Evstifeev Roman 2020-07-13 21:35:34 UTC
Still have this bug on openSUSE Tumbleweed with plasma 5.19.3
Comment 26 Krut Patel 2020-07-26 09:24:18 UTC
Same issue on Manjaro with Plasma 5.19.3.
Comment 27 Richard Ullger 2020-08-10 10:09:42 UTC
I don't see this issue.

Operating System: Arch Linux
KDE Plasma Version: 5.19.4
KDE Frameworks Version: 5.73.0
Qt Version: 5.15.0
Kernel Version: 5.7.12-arch1-1
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5 CPU M 430 @ 2.27GHz
Memory: 7.5 GiB of RAM
Graphics Processor: Mesa DRI Intel® HD Graphics

Set Battery and Brightness (Automatic Load) in system tray config to Always shown, icon appears in system tray.

When set to Shown when relevant, icon disappears. Disconnect AC, icon appears. Reconnect AC (still full charge), icon disappears. Reconnect AC (part discharge), icon remains until charged.
Comment 28 fbrummer 2020-09-27 08:44:24 UTC
Same problem here on OpenSuse Tumbleweed and Plasma 5.19.5
On first login battery is not shown. After I logout and login again bettery is shown.
Comment 29 Sebastian Kuhne 2020-10-02 14:11:08 UTC
Same problem here on openSUSE Tumbleweed. Login - Logout - Login required to make the battery symbol visible. 

Operating System: openSUSE Tumbleweed 20200925
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.74.0
Qt Version: 5.15.1
Kernel Version: 5.8.10-1-default
OS Type: 64-bit
Processors: 8 × AMD Ryzen 7 4700U with Radeon Graphics
Memory: 7.1 GiB of RAM
Graphics Processor: AMD RENOIR
Comment 30 josh.phelps2011 2020-10-07 17:56:48 UTC
I'm also seeing this bug on Manjaro Linux. It pops back up after a restart.

Operating System: Manjaro Linux
KDE Plasma Version: 5.19.5
KDE Frameworks Version: 5.74.0
Qt Version: 5.15.1
Kernel Version: 5.8.11-1-MANJARO
OS Type: 64-bit
Processors: 4 × AMD Ryzen 3 3250U with Radeon Graphics
Memory: 5.8 GiB of RAM
Graphics Processor: AMD RAVEN2
Comment 31 fbrummer 2020-10-17 09:38:27 UTC
This is fixed for me on OpenSuSe Tumbleweed with Plasma 5.20
Comment 32 Nate Graham 2020-10-17 15:03:41 UTC
Can anyone else confirm? Are other people who were seeing this in 5.19 able to confirm the fix in 5.20?
Comment 33 Tony 2020-10-17 15:13:23 UTC
(In reply to Nate Graham from comment #32)
> Can anyone else confirm? Are other people who were seeing this in 5.19 able
> to confirm the fix in 5.20?

It's here, in Neon it happened to me the other day, just after 5.20 update.
It is absolutely random, you don't see it for weeks and when you think an update has magically fixed it, it reappears. For this matter, I suspect it is some kind of race condition on start.
Comment 34 Nate Graham 2020-10-18 04:46:41 UTC
Bleh. :(
Comment 35 Berbigou 2020-10-23 07:30:43 UTC
Hello, I jump in to bump it up:
same problem here, randomly.

neofetch --off gives
OS: Arch Linux x86_64 
Host: VivoBook_ASUSLaptop X412DA_X412DA 1.0 
Kernel: 5.9.1-arch1-1 
Uptime: 19 mins 
Packages: 923 (pacman) 
Shell: zsh 5.8 
Resolution: 1920x1080 
DE: Plasma 5.20.1 
WM: KWin 
WM Theme: Breeze 
Theme: Breeze Dark [Plasma] 
Icons: breeze-dark [Plasma] 
Terminal: konsole 
CPU: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx (4) @ 2.600GHz 
GPU: AMD ATI 03:00.0 Picasso 
Memory: 1759MiB / 5949MiB
Comment 36 Nate Graham 2020-11-09 17:24:48 UTC
*** Bug 428896 has been marked as a duplicate of this bug. ***
Comment 37 elman 2020-11-09 17:35:28 UTC
Are you sure that Bug 428896 is duplicate? Because after system start I see icon just fine with correct percentage, but then it disappears when some state changes. 

Anyway I did see also problem described in this issue, but not with 5.20. So it seem this issue is fixed for me with 5.20.
Comment 38 Nate Graham 2020-11-09 19:00:43 UTC
Yes, it seems semi-random.
Comment 39 elman 2020-11-20 08:22:39 UTC
This issue just appeared on my Manjaro with 5.20.3. When I started notebook, there was no battery icon present. When I switched applet from disabled to always shown, it did appeared however with message that no battery was detected.
Comment 40 Nate Graham 2020-12-01 02:03:42 UTC
*** Bug 429703 has been marked as a duplicate of this bug. ***
Comment 41 Nate Graham 2020-12-07 16:24:12 UTC
*** Bug 430044 has been marked as a duplicate of this bug. ***
Comment 42 Marco Martin 2021-01-13 16:34:53 UTC
(In reply to Andrew Brouwers from comment #23)
> Then, after a kquitapp & kstart plasmashell, (which makes it appear pretty
> consistently):
> org.kde.Solid.PowerManagement


hmm, org.kde.Solid.PowerManagement *is* there both before and after, so doesn't seem an issue of the dbus server being absent.
Comment 43 David Edmundson 2021-01-28 22:57:43 UTC
Seems to affect very few people and reports are old.

#39 may be valid, but is describing something very unrelated. 

I've reviewed the modern code on this and it all looks fine now - though I do recall making some changes at some point to a hypothetical race with DBus activated items.

Closing unless someone can reproduce with 5.21 or provide some more useful information
Comment 44 Alex 2021-05-02 06:04:30 UTC
I just ran into this on Fedora 34 KDE Spin, running Plasma 5.21.4. org.kde.Solid.PowerManagement is in the output of that qdbus command for me. Is there any other info I can provide? Because I do still get this every now and then, and I'm experiencing it now.
Comment 45 Nate Graham 2021-05-11 18:19:57 UTC
Another report from 5.21: Bug 436911

Re-opening.
Comment 46 Nate Graham 2021-05-11 18:20:41 UTC
*** Bug 436911 has been marked as a duplicate of this bug. ***
Comment 47 Nate Graham 2021-05-12 12:44:12 UTC
*** Bug 436911 has been marked as a duplicate of this bug. ***
Comment 48 Alex 2021-06-23 08:58:39 UTC
Persists on plasma 5.22.1.

Not sure if its related, but this time, it happened after installing plasma/kf updates, and relogging without rebooting.

Is there anything I could look out for in my ~/.config/plasma-org.kde.plasma.desktop-appletsrc?
Comment 49 Alexandr Paliy 2021-06-24 21:08:06 UTC
Operating System: Gentoo Linux
KDE Plasma Version: 5.22.1
KDE Frameworks Version: 5.83.0
Qt Version: 5.15.2
Kernel Version: 5.10.45-gentoo (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Core™ i5-7200U CPU @ 2.50GHz
Memory: 15.5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 620

Happens to me too, but it's not consistently gone. Sometimes icon is present, sometimes it's not. I did not make any "deep" tests, but it feels like icon is missing after system went to sleep and woke up. After reboot icon [usually] is present again.
Comment 50 Alexandr Paliy 2021-06-24 21:21:02 UTC
Sorry for double-posting, I'll add some info.
When I say "icon is missing", ofc I mean that normally it would be shown (for example, now I have like 70% of battery, and in tray settings it is set to be always shown - but it is not, and it's also missing from "expanded" tray ("show hidden icons")).

I've tried to set "Always show all entries" in systray's properties - I can see everything except for battery :)

I don't know if that's still actual, but:
> David Edmundson 2020-06-29 14:40:55 UTC
> Can I see the output of:
> qdbus org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames

Here it is: https://gist.github.com/alexandrpaliy/06012b961bdb463ec3f488260ddba469
Comment 51 David Edmundson 2021-06-25 11:05:34 UTC
*** Bug 350365 has been marked as a duplicate of this bug. ***
Comment 52 Méven Car 2021-06-26 08:22:08 UTC
Probably relevant bug: https://gitlab.freedesktop.org/upower/upower/-/merge_requests/24 upstream

But in solid `Solid::Battery::ChargeState Battery::chargeState` we don't event use pending states, this marked "TODO".

I suspect some hardware use those states but not others.

I have a tentative patch to improve on the situation
https://invent.kde.org/frameworks/solid/-/merge_requests/43

If someone affected by the issue could test it, that would be great (I am not affected by the bug on my Dell laptop).
Comment 53 Sam Edwards 2021-07-10 23:52:00 UTC
I'm on 5.22.2 with frameworks 5.83.0 and rebooted 12 times, observing this bug 4 out of the 12 times, so it happens with roughly 30% probability.

After applying the above patch, the battery applet was not present on the very next boot, so it isn't sufficient to prevent this bug. :(

Killing and restarting the `plasmashell` process always restores the battery applet, though.
Comment 54 Erfan 2021-07-13 19:56:53 UTC
I found something can help to fix problem
add sleep 30 in /etc/xdg/autostart/powerdevil.desktop
like down
Exec= sleep 30 && /usr/lib/org_kde_powerdevil

i test in my system and its fixed

Operating System: Arch Linux 
KDE Plasma Version: 5.22.3
KDE Frameworks Version: 5.84.0
Qt Version: 5.15.2
Kernel Version: 5.12.15-arch1-1
Comment 55 Nate Graham 2021-07-13 20:34:24 UTC
Thanks for that information, but that's not a fix for everyone, that's a local workaround for you. :) Your workaround points to a race condition somewhere.
Comment 56 David Edmundson 2021-07-15 21:45:55 UTC
Asking a different question, does restarting powerdevil after an issue fix it?
Comment 57 Sam Edwards 2021-07-15 22:20:36 UTC
It appears that a restart of powerdevil does cause the battery applet to appear.

Are there any logging settings I should consider turning on? It feels like powerdevil/plasmashell are deciding that my laptop is really a desktop (i.e. no battery) when first deciding whether to instantiate the battery applet, as a result of not yet discovering the battery.
Comment 58 David Edmundson 2021-07-15 22:21:27 UTC
That is really useful information, we've constantly been debugging races in plasmashell <--> powerdevil

not powerdevil <--> upower
Comment 59 David Edmundson 2021-07-15 22:22:40 UTC
Please can someone insert this in their env (really really early, like /etc/profile.d/)

QT_LOGGING_RULES=org.kde.powerdevil.debug=true

and try and get me some logs.
Comment 60 Sam Edwards 2021-07-15 22:56:01 UTC
Created attachment 140102 [details]
org.kde.powerdevil debug log when battery applet does NOT appear
Comment 61 Sam Edwards 2021-07-15 23:02:50 UTC
Created attachment 140103 [details]
org.kde.powerdevil debug log when battery applet DOES appear

As requested, here are the logs. Nothing stands out to me as an obvious culprit, but maybe the (power)devil's in the details.

I was able to reproduce this issue without rebooting (I was starting the session from the terminal and using "log off" each time). It seemed to happen with a 90% rate under these circumstances. My upowerd PID was not changing between sessions, so we can rule out a race against upowerd's startup.

(Yes, my laptop is on battery power; detecting no AC power is expected.)

I'll next try restarting only powerdevil a few dozen times, unless a better diagnostic is proposed here.
Comment 62 Sam Edwards 2021-07-15 23:50:08 UTC
I have just spent the past half-hour restarting powerdevil and plasmashell, including giving each one a head-start ranging from a few ms to a few hundred ms. The battery applet appeared every single time without fail.

I can't make the issue occur in an *existing* session, only if I restart the entire desktop session does it (have a chance to) happen. Some third component must be involved at some level, so I tried adding kded5 to the mix for a few attempts to no avail.

I'll keep trying to find the relevant process(es) between which this race is happening.
Comment 63 David Edmundson 2021-07-17 00:06:25 UTC
Reading powerdevil code, we expect Battery::isPowerSupply to be valid at the time of adding the device. 

Otherwise we track it as a m_peripheralBatteriesPercent an never update which map it should be in.

My gut guess based on the above is that this isn't loaded on time? Are you able to build powerdevil and add some debug in onDeviceAdded? Or maybe in solid?

Failing that `sudo dbus-monitor --system` before logging in might contain some clues?
Comment 64 Sam Edwards 2021-07-17 05:27:17 UTC
I'm on Gentoo so adding arbitrary patches isn't even an inconvenience. :)

Sadly, Battery::isPowerSupply() is true even when the bug occurs, so I don't think it's that. But I have a better hypothesis as to what the culprit may be...

---

Two observations (for USERS):

a) This seems to affect only systemd systems. Is anyone experiencing this issue NOT USING SYSTEMD?

b) Using the systemdBoot option is a pretty good workaround for this issue:
kwriteconfig5 --file startkderc --group General --key systemdBoot true
...but that's probably only because (the user's) systemd starts things in an order that obviates the race condition, so not really a "fix" but should provide some relief until then.

---

A few things I've learned while debugging (for DEVELOPERS):

1) This issue is not specific to any video output method -- I have observed it on Wayland, Xorg, and now my current tests are done on Xephyr. I'm also now using a freshly-created user account, so we can rule out the possibility that this is because of some configuration setting that I changed to something other than its default.

2) This bug never happens when I restart plasmashell and/or powerdevil in an existing session, even if that session had the bug initially.

3) This bug never happens when I create a session for my test user account via sudo and run startplasma-x11 from it.

4) This bug occasionally happens when I create a session using machinectl, but only if I have recently run a Plasma session for that user from a TTY.

5) This bug often (>90%) happens when I run startplasma-x11 for my test user account via TTY.

So, this really smells like a race in interacting with logind, since it lines up pretty well with what logind considers a "fresh session" (scenario #3 above isn't a new session, scenario #4 is a new session but without a seat, and scenario #5 is a new session with a seat where powerdevil might want to dig deeper into the current session information, resulting in the bug).

I can see there's a fair amount of code in powerdevilpolicyagent.cpp; David, if you could highlight a few lines in there that look suspect, I'll be happy to see what I can do about tracing them.

In the meantime, I want to understand better why a `machinectl shell` session only has the bug if a Plasma session was run for the user from a TTY. I suspect it has something to do with which context spawned the dbus-daemon, but that's only a hunch.
Comment 65 Nate Graham 2021-07-17 11:45:55 UTC
I've been using the systemd startup feature since it was introduced and have never seen it happen FWIW.
Comment 66 Sam Edwards 2021-07-17 22:35:21 UTC
I think we're off to a false start by looking at powerdevil (although it may be useful to know WHY this happens)

I added a bunch of debug messages to applets/systemtray/dbusserviceobserver.cpp. When this issue happens, the "org.kde.Solid.PowerManagement" service is absent from the list(s) processed in DBusServiceObserver::serviceNameFetchFinished(), but present in the list output from qdbus; I also get a serviceUnregistered() for it when I kill powerdevil.

When restarting plasmashell, it comes back up during a time when the PowerManagement service is already registered, so it appears in the service list, and the battery applet appears.

When restarting powerdevil, plasmashell receives the service-registered event when PowerManagement is re-registered, and the battery applet appears.

The following are always present in the serviceNameFetchFinished lists, whether the issue happens or not: "org.kde.powerdevil.chargethresholdhelper", "local.org_kde_powerdevil", "org.kde.powerdevil.discretegpuhelper", "org.kde.powerdevil.backlighthelper"

So, powerdevil is alive at the time the systemtray initializes, but (probably because it's delayed by a few ms to talk to logind) hasn't registered the PowerManagement service yet; it instead gets registered during a time that, for some reason, the QDBusServiceWatcher doesn't report it.

The serviceRegistered callback is working normally prior to the call to initDBusActivatables, as well as after both lists are returned. On a launch where the issue doesn't happen, the PowerManagement service shows up right after the lists are processed. Is there perhaps some window where the QDBusPendingCallWatcher is temporarily paused (or some bug with DBus itself) where the systemtray is momentarily blind to new services, and the issue happens because powerdevil is delayed just enough to register PowerManagement during that blind period?
Comment 67 David Edmundson 2021-07-18 14:45:36 UTC
Thanks for all your help so far

I am unaware of any reason that would happen.

From a DBus POV we quite explicitly:
 - create a match rules for a service being added, no-op locally
 - start an async fetch of services
 - once that's done we locally connect the match rule created above (unblock the m_dbusSessionServiceNamesFetched flag)

In theory nothing is racey.

Two theories:
 - can you confirm we always call registerPlugin with the right arg before initDBusActivatables
  - can you put some debug at the top of serviceRegistered and see if we're getting in there at all, there is an early return there


Assuming that matches up with the theory of DBus going awry I'll try and write a smaller text based test case we can run against.
Comment 68 Sam Edwards 2021-07-18 17:33:10 UTC
Regarding theory 1: I was seeing the "Found DBus-able Applet" log for batterymonitor/PowerManagement before the init call
Regarding theory 2: My debug log was at the top of serviceRegistered

However, my debug log wasn't in the constructor's connect lambdas, so it's possible that the service is being registered while m_dbusSessionServiceNamesFetched is still false (i.e. after the handling of ListNames but before the delivery of the return value)

I'll check for that -- I might also want to get DBus running over TCP so I can capture the raw traffic.
Comment 69 Sam Edwards 2021-07-18 19:50:05 UTC
My hunch looks like it was correct; the new log message I added fires off when the bug occurs:

kde.systemtray: m_sessionServiceWatcher->serviceRegistered( "org.kde.Solid.PowerManagement" ) but m_dbusSessionServiceNamesFetched=false

At this point, I'm pretty confident that the order of events is:

1) DBusServiceObserver is created and initialized, with m_dbusSessionServiceNamesFetched=false as per defaults. Plugins are registered, and the watcher has watch patterns added.
2) DBusServiceObserver::initDBusActivatables() is called; the async ListNames() request is sent to the session DBus
3) Session DBus server prepares a list of all services presently registered
4) powerdevil finishes initialization and registers the PowerManagement service (this happens after step 3 above, so it's not in the list)
5) ???
6) m_sessionServiceWatcher's serviceRegistered signal fires to inform DBusServiceObserver of #4, above
7) The async ListNames() call returns the list from #3, above

When the issue does NOT happen, steps 6<->7 are reversed

The mystery is what's going on in #5, causing these callbacks to run in a different order. As I see it, there are two possible culprits:

a) DBus itself: It might be that, while DBus does have strict ordering guarantees between a given pair of endpoints, no ordering guarantees exist with respect to a third endpoint. Hence, the race is between the org.freedesktop.DBus service's reply to ListNames() and powerdevil's (connection's) broadcast announcement of a newly-registered service.
b) Qt: It's possible that, since one signal comes by way of a QDBusPendingCallWatcher, and the other by way of a QDBusServiceWatcher, there are races in how the signals themselves are handled.

I find both of these cases pretty hard to believe, though. 'A' shouldn't be possible since dbus-daemon is single-threaded: if it is preoccupied handling/returning a ListNames() call, it can't even see the service registration request yet. But 'B' shouldn't be possible either if Qt is dispatching these signals in FIFO order and in the same thread that's reading the incoming messages off of the connection. (Maybe it doesn't?)

I'm going to try to get my session DBus rebound to 127.0.0.1 and do a Wireshark capture on lo. It'd be very helpful to know the actual order that dbus-daemon is sending these things to plasmashell.
Comment 70 David Edmundson 2021-07-19 14:07:14 UTC
dbus-monitor --pcap does seem to capture the root calls we want and is open-able in wireshark

all UIs (regular dbus-monitor/bustle) seems to filter them out

but I can see our match rules name NameAcquired signals
Comment 71 David Edmundson 2021-07-19 14:19:05 UTC
As for Qt - there are threads involved. 

Everything is in it's own thread, and then dispatched to the main thread. This /should/ still maintain order.

There is a code path that if someone else (plasma-nm!) makes a blocking call, we queue up all pending messages, and do process things out of order, but the code for handling everything we do queue still looks fine?

The env QDBUS_DEBUG=1 might help us?
Comment 72 Sam Edwards 2021-07-19 21:01:30 UTC
I tried QDBUS_DEBUG=1; the extra output to the terminal slowed things down enough that the race stopped happening. I had to redirect stderr to a tmpfs-backed file to get the issue to happen again, but apparently redirecting stderr shuts off the other debug logs?

I had no luck with getting DBus running over TCP either. The session launched, but *slowly* -- it felt like the session launch kept blocking on something that had to time out before it could continue. Once again, no race condition. I didn't find it worthwhile to dig deeper.

The dbus-monitor --pcap worked, though. The messages are all in the expected order - the org.kde.Solid.PowerManagement registration signal arrives after the ListNames reply, despite the respective callbacks firing out of order. The timestamps indicate that the signal is ~32.4 ms after the ListNames request finishes, which is... quite the window, if those timestamps are accurate.

I'm not really sure how useful the dbus-monitor results are when DBus itself is a suspect, but I'm thinking we should be pointing the finger at Qt regardless. The single-threaded nature of dbus-daemon means they'd have to be *trying* to introduce message races, and with all of these threads in plasmashell, all it would take for a race there is for the two signals to take paths involving different threads. Perhaps most importantly, most of the earliest reports here are with Qt 5.15.0, which suggests this is a regression that appeared shortly after upgrading to the 5.15 series.

I don't understand what you mean about plasma-nm making a blocking call affecting plasmashell - isn't plasma-nm a different process? Wouldn't plasmashell be unaware of other calls into DBus and especially of whether those calls are performed in a blocking/nonblocking manner? Or are you talking about interactions between plasma-nm and plasmashell *via* DBus?

Happy to debug the queue replay code if you point me to the file that contains it! :)
Comment 73 Nate Graham 2021-09-21 21:32:00 UTC
*** Bug 442670 has been marked as a duplicate of this bug. ***
Comment 74 Bug Janitor Service 2021-10-15 15:18:42 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/61
Comment 75 David Edmundson 2021-10-16 23:22:10 UTC
FWIW, that commit mentioned above won't change anything.
Comment 76 Sam Edwards 2021-10-16 23:33:14 UTC
No worries, I figured as much. :)

Small update: I switched to a new laptop recently, and even when booting the exact same disk image, the problem doesn't happen for me at all anymore. I still have the old laptop for trying out patches, but I can't troubleshoot this problem quite as easily now.

This new laptop has 16 (logical) processors while the previous had 4. I'm wondering if this race only happens when all N threads used by KDE startup are forced to use a smaller set of processors (everybody else who has reported this has 8 or 4 processors). It might be worthwhile to try taking 12 of my processors offline and restarting KDE to see if that brings the race back.
Comment 77 ttv200 2021-11-17 11:38:42 UTC
Same here, Arch with Plasma 5.23.3 and Framework 5.88
With new laptop but LTS kernel (5.10.79)
Comment 78 ttv200 2021-11-17 11:39:33 UTC
*** Bug 444528 has been marked as a duplicate of this bug. ***
Comment 79 Roman Šmakal 2021-11-17 11:50:37 UTC
(In reply to ttv200 from comment #78)
> *** Bug 444528 has been marked as a duplicate of this bug. ***

Just to clarify, my report has similar symptoms, but battery icon is shown and it started happening at 5.23 i guess. It might be related, but not the same case.

Toshiba Z20t-C; Garuda Linux (it seems like lot of comments are from Arch-based distributions)

Any logs wanted?
Comment 80 Patrick Silva 2021-11-22 12:36:05 UTC
*** Bug 445911 has been marked as a duplicate of this bug. ***
Comment 81 thenujan 2021-12-08 04:34:53 UTC
applet says no batteries available even though my python script is able detect battery percentage and give me warning as it is low
Plasma 5.23
output of journalctl /usr/bin/plasmashell -n 100 | grep battery                                                                                            ✔  39s  
Dec 08 09:48:01 manjaro-minion plasmashell[1263]: file:///usr/share/plasma/plasmoids/org.kde.plasma.battery/contents/ui/PowerProfileItem.qml:136: TypeError: Cannot read property 'label' of undefined
Comment 82 Nowshed H. Imran 2021-12-08 08:25:42 UTC
I would like to one new observation.
Recently I had removed my batteries for a couple of days.
Even then, Battery applet is missing somethings.
Comment 83 Tommaso Fonda 2022-02-09 08:50:31 UTC
Lately, I have been experiencing this issue very often on my setup: openSUSE Tumbleweed, Plasma 5.23.5, KDE Frameworks 5.90.0, QT 5.15.2, Wayland.
While in the past years it happened very rarely (the battery icon in the tray would sometimes disappear after leaving the charger plugged in for some time, after reaching 100%), now it happens very often, and not only when charging. I log into my session, and the battery icon is already missing. Adding the "Battery and Brightness" object to the panel works as a workaround (I get the separate, bigger battery icon with the percentage in the panel, but outside the system tray).
Let me know if you need any additional piece of information/log/file/etc.
Comment 84 Berbigou 2022-02-18 08:32:47 UTC
Hi everyone,
I recently uninstalled tlp and reinstalled powerdevil on my Arch+Plasma KDE. Every power issue (including disappearing bluetooth) has gone.
Hope that helps.

neofetch --off gives
------------------ 
OS: Arch Linux x86_64 
Host: VivoBook_ASUSLaptop X412DA_X412DA 1.0 
Kernel: 5.16.9-arch1-1 
Uptime: 2 mins 
Packages: 1161 (pacman) 
Shell: zsh 5.8.1 
Resolution: 1920x1080 
DE: Plasma 5.24.1 
WM: KWin 
Theme: Breeze Dark [Plasma], Adwaita [GTK3] 
Icons: [Plasma], Adwaita [GTK3] 
Terminal: konsole 
Terminal Font: mononoki 12 
CPU: AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx (4) @ 2.600GHz 
GPU: AMD ATI Radeon Vega Series / Radeon Vega Mobile Series 
Memory: 1367MiB / 5943MiB
Comment 85 Nate Graham 2022-02-18 19:18:15 UTC
For the other people experiencing this, are you also using tlp?
Comment 86 Roman Šmakal 2022-02-18 19:27:46 UTC
Nate Graham píše v Pá 18. 02. 2022 v 19:18 +0000:
> https://bugs.kde.org/show_bug.cgi?id=422111
> 
> --- Comment #85 from Nate Graham <nate@kde.org> ---
> For the other people experiencing this, are you also using tlp?
> 

Not in my case, at least i really don't know about installing it and it
does not seem preinstalled on my distro.

I'm using Gnome now and did reinstall since laptop without battery life
was really hard to use, so i cannot be 100% sure.
Comment 87 chakli 2022-02-19 15:56:14 UTC
I too see this issue

from /etc/os-release
> NAME="openSUSE Tumbleweed"
> VERSION_ID="20220217"

> plasmashell 5.24.1

`upower -d`  correctly shows the battery state and charge level.

`tlp` seems to be installed but I have never run it manually before, not sure if it runs automatically.

    $ systemctl status tlp
    ○ tlp.service - TLP system startup/shutdown
         Loaded: loaded (/usr/lib/systemd/system/tlp.service; disabled; vendor preset: disabled)
         Active: inactive (dead)


The CPU is Intel celeron, if it makes any difference being slower and all.
Comment 88 Tommaso Fonda 2022-02-20 12:23:05 UTC
(In reply to Nate Graham from comment #85)
> For the other people experiencing this, are you also using tlp?

Nope. Actually, I have used it for a long time without ever experiencing this issue, and recently I uninstalled it and started using tuned instead. It was around this time that I first started experiencing this issue (I know this is probably a coincidence, but I am reporting it for the sake of completeness).
Comment 89 flux 2022-02-20 17:36:51 UTC
For workaround, go to System Tray Settings/Entries panel.
Set 'Battery and Brightness' to 'Disabled' (Apply).
Then set it back to 'Shown when relevant' (Apply).

Does this give a clue as to where the bug lies?
Comment 90 chakli 2022-02-20 20:46:32 UTC
(In reply to flux from comment #89)
> For workaround, go to System Tray Settings/Entries panel.
> Set 'Battery and Brightness' to 'Disabled' (Apply).
> Then set it back to 'Shown when relevant' (Apply).

This does not seem to work for me, but restarting plasmashell works.

If we are suspecting startup order of something, then this is my journalctl log. I also have autologin enabled.

$ journalctl -b | grep autostart

Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/org.kde.plasmashell.desktop" ("/usr/bin/plasmashell")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/polkit-kde-authentication-agent-1.desktop" ("/usr/lib64/libexec/polkit-kde-authentication-agent-1")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/xprop-kde-full-session.desktop" ("/usr/bin/xprop", "-root", "-format", "KDE_FULL_SESSION", "32a", "-set", "KDE_FULL_SESSION", "1")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/xembedsniproxy.desktop" ("/usr/bin/xembedsniproxy")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/baloo_file.desktop" ("/usr/lib64/libexec/baloo_file")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/powerdevil.desktop" ("/usr/lib64/libexec/org_kde_powerdevil")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/kaccess.desktop" ("/usr/bin/kaccess")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/pulseaudio.desktop" ("/usr/bin/start-pulseaudio-x11")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/gmenudbusmenuproxy.desktop" ("/usr/bin/gmenudbusmenuproxy")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/xdg-user-dirs.desktop" ("/usr/bin/xdg-user-dirs-update")
Feb 20 21:59:16 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/geoclue-demo-agent.desktop" ("/usr/libexec/geoclue-2.0/demos/agent")
Comment 91 chakli 2022-02-21 14:09:36 UTC
(In reply to flux from comment #89)
> For workaround, go to System Tray Settings/Entries panel.
> Set 'Battery and Brightness' to 'Disabled' (Apply).
> Then set it back to 'Shown when relevant' (Apply).

This does not seem to work for me, but restarting plasmashell works.

If we are suspecting startup order of something, then this is my journalctl log. I also have autologin enabled.

$ journalctl -b | grep autostart

Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/org.kde.plasmashell.desktop" ("/usr/bin/plasmashell")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/polkit-kde-authentication-agent-1.desktop" ("/usr/lib64/libexec/polkit-kde-authentication-agent-1")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/xprop-kde-full-session.desktop" ("/usr/bin/xprop", "-root", "-format", "KDE_FULL_SESSION", "32a", "-set", "KDE_FULL_SESSION", "1")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/xembedsniproxy.desktop" ("/usr/bin/xembedsniproxy")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/baloo_file.desktop" ("/usr/lib64/libexec/baloo_file")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/powerdevil.desktop" ("/usr/lib64/libexec/org_kde_powerdevil")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/kaccess.desktop" ("/usr/bin/kaccess")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/pulseaudio.desktop" ("/usr/bin/start-pulseaudio-x11")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/gmenudbusmenuproxy.desktop" ("/usr/bin/gmenudbusmenuproxy")
Feb 20 21:59:14 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/xdg-user-dirs.desktop" ("/usr/bin/xdg-user-dirs-update")
Feb 20 21:59:16 laptop plasma_session[1605]: org.kde.plasma.session: Starting autostart service  "/etc/xdg/autostart/geoclue-demo-agent.desktop" ("/usr/libexec/geoclue-2.0/demos/agent")
Comment 92 Christoph Sarnowski 2022-02-27 19:09:19 UTC
Hi everyone,
I also want to provide some more (maybe useful) information.
I am using plasma-desktop  5.24.2-1 on arch linux and also experience this bug (randomly either showing the battery monitor, or not).
Hardware is a Thinkpad T460s.

But in addition to the battery icon missing, also my hotkeys for adjusting the display brightness do not work.
I killed & restarted org_kde_powerdevil, and that made my hotkeys work again, but still no battery icon (just a display icon). Hovering that icon, it said something like "No batteries".

Restarting plasmashell, as mentioned above, fixed everything.
Comment 93 Jason 2022-03-01 12:45:53 UTC
Hi.

I'm having the same issue and I'm wondering if powerdevil is required for the battery indicator to work. I already have upower and tlp installed and I can get battery readings and set thresholds to it. I can also see battery information on lock screen and kinfocenter.

Battery icon setting is 'always show'. I've tried with the separate widget but it doesn't show charge percentage and settings don't open, which I assume it's caused by missing powerdevil package.

All in all, I'm not installing powerdevil just because I'm already covered with tlp and I'm not sure if it will cause any conflicts.
Comment 94 Nate Graham 2022-03-01 14:09:14 UTC
Yes it is, and no it won't conflict.
Comment 95 Jason 2022-03-01 16:05:12 UTC
(In reply to Nate Graham from comment #94)
> Yes it is, and no it won't conflict.

Thanks! Now it shows. I'm on Arch and I've installed powerdevil-light to avoid bringing a networkmanager-qt which I don't use.

I was expecting the icon to show up when charge is below the threshold, 40% in my case. Setting is 'visible when important' and laptop is connected to AC, maybe that's why.
Comment 96 Nate Graham 2022-04-20 15:32:17 UTC
Git commit ff834fc96548a0d61def108dea6f229437c6c8d7 by Nate Graham, on behalf of Jolene K.
Committed on 20/04/2022 at 15:32.
Pushed by ngraham into branch 'master'.

systemtray: Fix race in DBusServiceObserver

When a service appears right after the ListNames() call finished, but
before the QDBusPendingCallWatcher is set up, the ::serviceRegistered
signal will be queued before the ListNames() response. As a result,
the service will be ignored by DBusServiceObserver.

Switching to QDBusInterface::callWithCallback() ensures that the
result slot is queued as soon as the response arrives, thus avoiding
the race.

Credits go to Sam Edwards for identifying the problem in
https://bugs.kde.org/show_bug.cgi?id=422111#c69
FIXED-IN: 5.24.5

M  +38   -26   applets/systemtray/dbusserviceobserver.cpp
M  +7    -2    applets/systemtray/dbusserviceobserver.h

https://invent.kde.org/plasma/plasma-workspace/commit/ff834fc96548a0d61def108dea6f229437c6c8d7
Comment 97 Nate Graham 2022-04-20 15:40:16 UTC
Git commit 757b5e8c27a43a42d6a28c8dda66be08bf231b6a by Nate Graham, on behalf of Jolene K.
Committed on 20/04/2022 at 15:40.
Pushed by ngraham into branch 'Plasma/5.24'.

systemtray: Fix race in DBusServiceObserver

When a service appears right after the ListNames() call finished, but
before the QDBusPendingCallWatcher is set up, the ::serviceRegistered
signal will be queued before the ListNames() response. As a result,
the service will be ignored by DBusServiceObserver.

Switching to QDBusInterface::callWithCallback() ensures that the
result slot is queued as soon as the response arrives, thus avoiding
the race.

Credits go to Sam Edwards for identifying the problem in
https://bugs.kde.org/show_bug.cgi?id=422111#c69


(cherry picked from commit 3751f49cc5be219e63c7fae1df9f1b6e77f5762a)

M  +38   -26   applets/systemtray/dbusserviceobserver.cpp
M  +7    -2    applets/systemtray/dbusserviceobserver.h

https://invent.kde.org/plasma/plasma-workspace/commit/757b5e8c27a43a42d6a28c8dda66be08bf231b6a