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

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.

https://invent.kde.org/plasma/powerdevil/-/merge_requests/472 made the Brightness and Color applet react to D-Bus service (un)register events as well. Plasma 6.3 will have this fix.

https://invent.kde.org/plasma/powerdevil/-/merge_requests/463 is one final fix to make it (hopefully) perfect. Let's close this bug once that goes into 6.3 as well.

Git commit 6f668270a389322ccdb8b8cc92eea308d087fca8 by Jakob Petsovits.
Committed on 08/12/2024 at 03:04.
Pushed by jpetso into branch 'master'.

applets/brightness: Never miss a display on brightness service registration

Since commit c8f60bbf, the display list gets updated when the
org.kde.ScreenBrightness service (provided by PowerDevil) starts
or restarts. This exposed a race condition that was already present,
but now gets triggered regularly due to tighter timing.

The sequence of events reproducing this bug goes like this:

1. The D-Bus service appears, `onServiceRegistered()` is invoked.
2. `queryAndUpdateDisplays()` starts retrieving display properties.
3. Soon after the D-Bus service came up, it adds another display.
4. `queryAndUpdateDisplays()` finishes.
5. Only at this point we connect to D-Bus display change signals.

In this sequence, the display from (3) is missed and won't show up
in the applet until another display change happens at a later point.

Now that the display model is robust against duplicate insertions,
we can simply move `queryAndUpdateDisplays()` from the start of
`onServiceRegistered()` to the end of the function, at which point
D-Bus signal connections are already set up. This ensures that
no display additions will be missed, even if they happen immediately
after service startup.
Related: bug 486067

M  +10   -10   applets/brightness/plugin/screenbrightnesscontrol.cpp

https://invent.kde.org/plasma/powerdevil/-/commit/6f668270a389322ccdb8b8cc92eea308d087fca8