Created attachment 170772 [details] Widgets placed: Left - after reboot, Right - before reboot SUMMARY I am using a laptop with KDE Plasma 6.1.0 and use the Brightness and Color and Battery Monitor widgets to monitor and modify device options like display brightness, battery levels and more. After updating to 6.1.0, those widgets have a serious problem. They do not load any information or options for the devices after reboot. When creating a new widget, they load the information correctly. In the provided screenshot on the left, you can see the widgets placed after rebooting, and on the right before rebooting. STEPS TO REPRODUCE 1. Create a Battery Monitor/Brightness and Color widget - it shows the correct information and options 2. Reboot the system 3. Observe the created widget - it is in a broken state showing no information about the devices 4. Create a new widget again - it shows the correct information and options OBSERVED RESULT The widgets do not show device specific information and options, like display brightness or battery levels. EXPECTED RESULT The widgets should show the information and options for the specific devices correctly. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION Device: MSI Pulse GL66 11UEK
I have the same issue, on a Lenovo IdeaPad Pro 5i. It seems you can also make the widgets work again by running `plasmashell --replace`
Do you observe any suspicious activity in the system journal? It seems like PowerDevil service fails to load at all, as indicated by the user-facing error message in the top-right applet on the screenshot.
The PowerDevil service looks like it doesn't crash, however these p4 journal lines seem to be new compared to when it worked: Jun 23 07:33:35 arch org_kde_powerdevil[1180]: qt.core.qobject.connect: QObject::disconnect: Unexpected nullptr parameter Jun 23 07:33:35 arch org_kde_powerdevil[1180]: qt.core.qobject.connect: QObject::disconnect: Unexpected nullptr parameter
Well, that's not much but that's something. Unfortunately, Qt logs don't show you the whole stacktrace by default, so it could be anywhere. Is this reproducible on a new user?
I can't reproduce the issue on a fresh user.
Some questions for you to answer with your current user account that's exhibiting the bug: 1. How many of these widgets do you end up having after reboot? More than one? (Include the one in the system tray) 2. Does the issue reproduce if you make absolutely sure you only have *one* instance of each of these widgets on reboot? E.g. by disabling them from the system tray and only having one of each on the desktop. 3. When it happens, is powerdevil running? 4. Can you get journal logs for it powerdevil, or systemd service status/logs, or a crash log for it, or something of the sort?
*** Bug 489196 has been marked as a duplicate of this bug. ***
> 1. How many of these widgets do you end up having after reboot? More than > one? (Include the one in the system tray) I use exactly one, the Power Management one. If I add the Brightness one it also doesn't work on reboot. Both of them seem to work without a plasmashell restart if they're shown through the system tray, even if the relevant widgets are still present elsewhere, where they don't work. > 2. Does the issue reproduce if you make absolutely sure you only have *one* > instance of each of these widgets on reboot? E.g. by disabling them from the > system tray and only having one of each on the desktop. Yes, but they do work if shown through the system tray instead of the widget itself. Maybe something is getting loaded too early or too late for the standalone widgets to function properly? > 3. When it happens, is powerdevil running? Yes. > 4. Can you get journal logs for it powerdevil, or systemd service > status/logs, or a crash log for it, or something of the sort? https://pastebin.com/xyteMpVb is all the mentions of powerdevil in the logs. No systemd services failed to load.
Thanks. I can reproduce it.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/425
Git commit 8e698dbcdc9ce95095ea2739713fde05ca4822f5 by Jakob Petsovits. Committed on 19/09/2024 at 18:06. Pushed by jpetso into branch 'master'. applets/batterymonitor: React to D-Bus service (un)register events Previously, the "Power and Battery" applet only checked for the presence of PowerDevil's D-Bus services once when it starts up. This appears to (mostly?) work for applets embedded in a panel, but does not work for applets on the desktop itself. Likely there's a timing issue and applets on the desktop start sooner than PowerDevil will advertise its services. A better way to work is for the applet to monitor the bus for when the relevant services appear or disappear. When observing a service registered or unregistered event, the applet gets set up accordingly. This fixes the race condition for two out of three applet parts (power profiles, inhibitions) but does not fix battery status; the data for that is coming from `BatteryControlModel` in plasma-workspace. A similar fix will have to be implemented there. Related: bug 489003, bug 492859, bug 492945 M +88 -12 applets/batterymonitor/plugin/powermanagementcontrol.cpp M +10 -2 applets/batterymonitor/plugin/powermanagementcontrol.h M +77 -1 applets/batterymonitor/plugin/powerprofilescontrol.cpp M +10 -1 applets/batterymonitor/plugin/powerprofilescontrol.h https://invent.kde.org/plasma/powerdevil/-/commit/8e698dbcdc9ce95095ea2739713fde05ca4822f5
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4729
Git commit 0979a34248efa8eac087e418a4cf4419549ece0c by Jakob Petsovits. Committed on 20/09/2024 at 12:26. Pushed by jpetso into branch 'master'. components/batterycontrol: React to D-Bus service (un)register events Previously, the "Power and Battery" applet only checked for the presence of PowerDevil's D-Bus services once when it starts up. This appears to (mostly?) work for applets embedded in a panel, but does not work for applets on the desktop itself. Likely there's a timing issue and applets on the desktop start sooner than PowerDevil will advertise its services. A better way to work is for the applet to monitor the bus for when the relevant services appear or disappear. When observing a service registered or unregistered event, the applet gets set up accordingly. This fixes the race condition for one out of three applet parts (battery state) but does not fix power profiles & inhibitions; these were fixed separately in the powerdevil repository via commit 8e698dbc. Related: bug 489003, bug 492859, bug 492945 M +82 -15 components/batterycontrol/batterycontrol.cpp M +6 -1 components/batterycontrol/batterycontrol.h https://invent.kde.org/plasma/plasma-workspace/-/commit/0979a34248efa8eac087e418a4cf4419549ece0c
A possibly relevant merge request was started @ https://invent.kde.org/plasma/powerdevil/-/merge_requests/428
Git commit 5e8cd380806da20d0b12bf97a3629ac70aa2b77c by Jakob Petsovits. Committed on 23/09/2024 at 21:41. Pushed by jpetso into branch 'Plasma/6.2'. applets/batterymonitor: React to D-Bus service (un)register events Previously, the "Power and Battery" applet only checked for the presence of PowerDevil's D-Bus services once when it starts up. This appears to (mostly?) work for applets embedded in a panel, but does not work for applets on the desktop itself. Likely there's a timing issue and applets on the desktop start sooner than PowerDevil will advertise its services. A better way to work is for the applet to monitor the bus for when the relevant services appear or disappear. When observing a service registered or unregistered event, the applet gets set up accordingly. This fixes the race condition for two out of three applet parts (power profiles, inhibitions) but does not fix battery status; the data for that is coming from `BatteryControlModel` in plasma-workspace. A similar fix will have to be implemented there. Related: bug 489003, bug 492859, bug 492945 M +88 -12 applets/batterymonitor/plugin/powermanagementcontrol.cpp M +10 -2 applets/batterymonitor/plugin/powermanagementcontrol.h M +77 -1 applets/batterymonitor/plugin/powerprofilescontrol.cpp M +10 -1 applets/batterymonitor/plugin/powerprofilescontrol.h https://invent.kde.org/plasma/powerdevil/-/commit/5e8cd380806da20d0b12bf97a3629ac70aa2b77c
Git commit 43ca4f3bf083651c2ac8b803596e3827ed8d5e76 by Jakob Petsovits. Committed on 23/09/2024 at 21:48. Pushed by jpetso into branch 'Plasma/6.2'. components/batterycontrol: React to D-Bus service (un)register events Previously, the "Power and Battery" applet only checked for the presence of PowerDevil's D-Bus services once when it starts up. This appears to (mostly?) work for applets embedded in a panel, but does not work for applets on the desktop itself. Likely there's a timing issue and applets on the desktop start sooner than PowerDevil will advertise its services. A better way to work is for the applet to monitor the bus for when the relevant services appear or disappear. When observing a service registered or unregistered event, the applet gets set up accordingly. This fixes the race condition for one out of three applet parts (battery state) but does not fix power profiles & inhibitions; these were fixed separately in the powerdevil repository via commit 8e698dbc (master branch) / commit 5e8cd380 (Plasma/6.2). Related: bug 489003, bug 492859, bug 492945 M +82 -15 components/batterycontrol/batterycontrol.cpp M +6 -1 components/batterycontrol/batterycontrol.h https://invent.kde.org/plasma/plasma-workspace/-/commit/43ca4f3bf083651c2ac8b803596e3827ed8d5e76
The issue is fixed for the Power and Battery widget but persists for the Brightness and Color widget.