SUMMARY Guys - this is a report of the symptoms of bug #422111 appearing again. bug #422111 is logged as resolved/closed and I don't know if it needs re-opening or if I should log a new bug, hence submitting this for triage. Sadly I am not able to in depth debug the issues described in the previous bug, but I can confirm that I can reliably reproduce the non working (or working) of the battery indicator by varying the sleep workaround in the power devil.desktop file. STEPS TO REPRODUCE 1. Start Laptop as usual after update to Manjaro/Kernel 6.1.7 OBSERVED RESULT 1. Battery level not displayed in KDE desktop, though it is on login screen, regardless of on mains or on battery boot. EXPECTED RESULT 1. Battery level displayed always (if set) or when running on Battery (When always display not set) SOFTWARE/OS VERSIONS OS: Manjaro Linux x86_64; systemd boot. Kernel: 6.1.7-1-Manjaro KDE Plasma Version: Plasma 5.26.5 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 ADDITIONAL INFORMATION What I have done to verify that it is the bug rather than something completely new... 1. Set Battery/Brightness widget in system tray to Always On. 2. Widget displayed with message "No Battery" on hover. CLI tools show both battery present and charge levels correctly (as in original bug) 3. Use work around suggested in bug 422111 and Set the Exec= sleep n &&... line in /etc/xdg/autostart/powerdevil.desktop such that n>=21 (original work around says 30, I played around to find the approximate minimum that, on my machine, worked around the bug) 4. Restart laptop 5. Battery level is displayed correctly on login screen and also in the system tray. CLI tools still report battery and charge levels. 6. Set Set the Exec= sleep n &&... line in /etc/xdg/autostart/powerdevil.desktop such that n<21 7. Restart laptop 8. Login screen battery level displays correctly 9. System Tray Widget displayed with message "No Battery" on hover. CLI tools show both battery present and charge levels correctly (as in original bug) 10. reset sleep to n>=21 11. restart and everything works as expected.
Created attachment 156215 [details] Screenshot of the failed condition This is when the bug has occurred. The brightness icon is here instead of the battery, and the tool tip reports batteries are unavailable.
Created attachment 156216 [details] Screenshot of the failed condition This one has the tooltip
I'm seeing the same thing on my system so I thought I would try to add my findings here... SUMMARY I am also seeing the missing battery applet bug described here and in 422111 on the latest version of plasmashell (5.26.5). The bug is very sporadic/random in nature but can be recurrently triggered with enough attempts. STEPS TO REPRODUCE Start a desktop session from a tty (i.e. with the startplasma-x11 xinit script). If the battery applet shows up normally, log out back to tty and launch the x11 session again until it occurs. The bug also shows up when starting the session from a display manager like sddm. I just used the tty method because it was quicker to repeatedly launch sessions. Note: The bug only triggers on new session startups. Simply restarting plasmashell in an already running session will not cause it. Note that it is highly random to trigger. I have observed up to 24 attempts until it triggers the bug. Other times it takes less attempts. OBSERVED RESULT Battery icon is missing from the system tray. It is replaced by the brightness icon and the tool tip reports "No Batteries Available". This is shown in the screenshots. EXPECTED RESULT The battery level should always be reported since this is a battery powered laptop. SOFTWARE/OS VERSIONS Operating System: Slackware Live 15.0 KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 Kernel Version: 6.1.11 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-6200U CPU @ 2.30GHz Memory: 7.6 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 520 Manufacturer: Dell Inc. Product Name: XPS 13 9350 ADDITIONAL INFORMATION UPower and solid-hardware5 both report the battery is present in any case. It is just the icon in plasmashell that is incorrect. When the battery icon is missing, running 'org_kde_powerdevil --replace' has no effect. When powerdevil restarts, the icon disappears and reappears as the brightness icon and still reports batteries are not available. Only restarting plasmashell returns it to normal. This bug seems related to UPower. Slackware is still packaging UPower 0.99.13 and the bug is not present with the combination of UPower 0.99.13 and Plasma 5.26.5. I've tested newer UPower versions (0.99.14 up to 0.99.20) and the bug can be triggered on all newer versions with enough login attempts. I'm not sure what happened between 0.99.13 to 0.99.14 that might cause this to trigger but it seemed related and worth mentioning. I hope this information is helpful. I can try to provide more debug output if needed but I am not experienced with the inner workings of upower, powerdevil, and plasmashell. - Bob
I updated to the latest plasma release and can still trigger this battery applet bug after enough login/logout cycles. Here's the "About" copy paste, for the record: Operating System: Slackware Live 15.0 KDE Plasma Version: 5.27.0 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 Kernel Version: 6.1.12 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-6200U CPU @ 2.30GHz Memory: 7.6 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 520 Manufacturer: Dell Inc. Product Name: XPS 13 9350 The bug is the same: A random chance that upon login, the battery applet thinks there's no battery and only shows the icon and controls for screen brightness/keyboard brightness instead. The tooltip over the "battery applet" in this state reports "No Batteries Available". This would seem that batterymonitor thinks there's no batteries, even though UPower reports 'IsPresent' as true, along with solid-hardware5 reporting "Battery.present = true (bool)" when looking at the details of my battery. Somehow there is a very small chance the applet gets the wrong information at session startup and stays that way until plasmashell is restarted. Seems like a timing issue but I dont understand enough about how the applet gets its data to make a proper guess. If there's anything else I can supply please let me know. Everything seems to report a present and functional battery except the applet. Upower and soild reports arn't anything to look at because they report a present battery and charge status as normal.
In regular use I have a non-systemd system and plasmashell and powerdevil get started via their /etc/kde/xdg/autostart/ scripts. They are not always started in the same order on my system. Sometimes they are closer together, sometimes further apart, sometimes in reverse order. It would seem that on some of these occasions there is a timing that hits this bug. With that in mind, I managed to reproduce this bug from a running plasma session by opening konsole and running the following as my test user: # /usr/lib64/libexec/org_kde_powerdevil --replace & /usr/bin/plasmashell --replace Most of the time the two will restart as normal. However on rare occasion it will start with the bugged batterymonitor applet where it fails to report about my laptop's battery. Racing the two programs this way seems to trigger it as well, although only on rare occasion. The plasmashell console spew after the --replace command was is same everytime when the battery applet is working normally. When the applet gets bugged, the only difference is that plasmashell console will output the following: file:///usr/share/plasma/plasmoids/org.kde.plasma.battery/contents/ui/CompactRepresentation.qml:61:17: Unable to assign [undefined] to int This line gets emitted when clicking on the icon in the system tray when the battery icon that should be there is bugged and replaced with the display brightness icon instead. I am not a kde/plasma expert so its hard to know what to look into next here. Any insight on what to try next from a dev would be appreciated.
As an addon to my last comment, that line: file:///usr/share/plasma/plasmoids/org.kde.plasma.battery/contents/ui/CompactRepresentation.qml:61:17: Unable to assign [undefined] to int Also gets emitted periodically from plasmashell while the battery applet is bugged, probably due to periodic battery discharge updates in the backend somewhere. Seems like battery information is being sent to the applet, but once its in the bugged state it will not update otherwise. The only thing that clears it is a restart of plasmashell so the applet reloads to get the proper data.
> file:///usr/share/plasma/plasmoids/org.kde.plasma.battery/contents/ui/CompactRepresentation.qml:61:17: Unable to assign [undefined] to int Here is the line itself: > property int percent: root.isConstrained ? pmSource.data["Battery"]["Percent"] : model["Percent"] > And for the context, the model is > model: root.isConstrained ? 1 : root.batteries > where `isConstrained` is basically "is it on a panel?" as opposed to "nope, it is on a desktop". Assuming from your screenshot that it is on a panel, the code should take this path: `pmSource.data["Battery"]["Percent"]`. So it must the Plasma DataEngine not providing required objects/properties either for .data or for .data["Battery"] expression. What does not make sense to me, is why it gets emitted periodically. Because once a binding is failed to evaluate, the engine would not keep track of the properties which it failed to get. However, it *probably* still was able to bind on `data` change signal, which is enough to trigger attempts to re-evaluate data["something"]["blahblah"]. So there must be a bug either in "powermanagement" data engine, or the way we handle it in applet's code.
I reproduce the issue on 5.27.2 with kernel 5.19 and upower 0.99.20 (kubuntu)
Latest update (Manjaro is a rolling release so latest is rather vague.... update was applied between 10-apr-2023 and 13-apr-2023) seems to have removed the symptoms. The powerdevil config file has had the exec reverted to default and the battery indicator (logged in or on the login screen) now displays battery % as expected. I don't think this is fixed (for a start no-one has closed this bug :) ), but the symptoms have gone away for the moment with the newer Plasma/Plasma Frameworks release. Definitely pointing to a timing bug IMHO. Operating System: Manjaro Linux KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.1.23-1-MANJARO (64-bit)
*** Bug 471931 has been marked as a duplicate of this bug. ***