STEPS TO REPRODUCE 1. play an audio/video with VLC player or Haruna 2. click on Battery applet in the system tray 3. OBSERVED RESULT "Manually block sleep and screen locking" option is active, but the applet does not tell why, like on Plasma 5. EXPECTED RESULT if the power management is inhibited, the Battery applet should tell why SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.27.80 KDE Frameworks Version: 5.240.0 Qt Version: 6.6.0 Graphics Platform: Wayland
Can reproduce. Seems like a recent regression, as I recall this working just a week or two ago.
> qt.dbus.integration: Could not connect "org.kde.Solid.PowerManagement.PolicyAgent" to inhibitionsChanged(QList<InhibitionInfo>, QStringList) : Unregistered input type in parameter list: QList<InhibitionInfo> error connecting to inhibition changes via dbus sounds related
(In reply to Nicolas Fella from comment #2) > > qt.dbus.integration: Could not connect "org.kde.Solid.PowerManagement.PolicyAgent" to inhibitionsChanged(QList<InhibitionInfo>, QStringList) : Unregistered input type in parameter list: QList<InhibitionInfo> > error connecting to inhibition changes via dbus > > sounds related Ah, quite possibly my fault with the recent sync manusl inhibition state fix, I'll look into it
> Ah, quite possibly my fault with the recent sync manusl inhibition state fix Nope, reverting it doesn't fix the bug. And that DBus error sounds not directly related to that change anyway, so I'll look into that.
I'm getting that signal fine with dbus-monitor so currently out of ideas why the applet's data engine fails to connect to it.
Apparently the dbus connection error is a bug in Qt that will be fixed in the next release: https://codereview.qt-project.org/c/qt/qtbase/+/513362. It may need another patch in the battery applet on top of it that I have a draft for and will revisit once the upstream fix is out.
*** Bug 477120 has been marked as a duplicate of this bug. ***
Can confirm it's fixed in Qt 6.6 for me.
(In reply to Nate Graham from comment #8) > Can confirm it's fixed in Qt 6.6 for me. Just the DBus connection failure or this bug?
The bug itself. I now see explanations again.
The bug persists on Arch Linux running Plasma 6 beta. Operating System: Arch Linux KDE Plasma Version: 5.90.0 KDE Frameworks Version: 5.246.0 Qt Version: 6.6.1 Graphics Platform: Wayland
Created attachment 163670 [details] Works for me
(In reply to Nate Graham from comment #12) > Created attachment 163670 [details] > Works for me I'm on Arch, and have the same problem. It only shows inhibitors present when the applet is loaded, not anything afterwards. 1. Ensure no inhibitor is present. 2. `systemd-inhibit bash` 3. In another konsole: `plasmoidviewer --applet org.kde.plasma.battery` 4. Click on the icon. It shows `bash` as the inhibitor. 5. Quit `bash`, then run `systemd-inhibit bash` again. 6. The bug. Also notice that the kscreen applet shows the same info correctly, with roughly the same code. And I added some logging in the battery applet's DataSource.onDataChanged to verify that it indeed received the inhibitor list correctly. The bug probably is not in dbus, but in the applet's own logic.
The current implementation doesn't make sense at all... The manual switch is bound to the data engine "PowerManagement" "Has Inhibition": https://github.com/KDE/plasma-workspace/blob/e254bf301a560b9d6d70968ac43a587edab7fe19/applets/batterymonitor/package/contents/ui/PowerManagementItem.qml#L41 Which bounds to org.freedesktop.PowerManagement.Inhibit.HasInhibitChanged: https://github.com/KDE/plasma-workspace/blob/de5a5dbf63c5d1fb91c1cf3a3f45553b9cca417b/dataengines/powermanagement/powermanagementengine.cpp#L219 The problem is the FDO service returns HasInhibit=true for *any* inhibitors. So this code would treat any inhibitor as manually enabled in the applet. The correct implementation would be that Powerdevil manages a special "KDE manual inhibitor" whose state can be queried individually. BTW, I don't see why the applet hides inhibitors when the manual switch is on.
Now it shows the inhibition after setting the manual inhibition switch to off again, but it still incorrectly turns the manual inhibition switch on the first time. (In reply to Jin Liu from comment #14) > The current implementation doesn't make sense at all... > > The manual switch is bound to the data engine "PowerManagement" "Has > Inhibition": > https://github.com/KDE/plasma-workspace/blob/ > e254bf301a560b9d6d70968ac43a587edab7fe19/applets/batterymonitor/package/ > contents/ui/PowerManagementItem.qml#L41 > > Which bounds to org.freedesktop.PowerManagement.Inhibit.HasInhibitChanged: > https://github.com/KDE/plasma-workspace/blob/ > de5a5dbf63c5d1fb91c1cf3a3f45553b9cca417b/dataengines/powermanagement/ > powermanagementengine.cpp#L219 > > The problem is the FDO service returns HasInhibit=true for *any* inhibitors. > So this code would treat any inhibitor as manually enabled in the applet. > > The correct implementation would be that Powerdevil manages a special "KDE > manual inhibitor" whose state can be queried individually. > > BTW, I don't see why the applet hides inhibitors when the manual switch is > on. That's correct, my mentioned drafted fix addresses this, will test again.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3654
(In reply to Jin Liu from comment #14) > BTW, I don't see why the applet hides inhibitors when the manual switch is > on. I think the idea was that the information is redundant since when the manual inhibition is on, it won't go to sleep anyway. But the same applies to having more than one app inhibition, and it just makes the logic more complicated, so I would be fine with changing it to simply always showing all active inhibition sources.
(In reply to Natalie Clarius from comment #17) > (In reply to Jin Liu from comment #14) > > > BTW, I don't see why the applet hides inhibitors when the manual switch is > > on. > > I think the idea was that the information is redundant since when the manual > inhibition is on, it won't go to sleep anyway. But the same applies to > having more than one app inhibition, and it just makes the logic more > complicated, so I would be fine with changing it to simply always showing > all active inhibition sources. Yeah. And also it would be consistent with the kscreen applet in that way.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3655
Git commit feaa8903e809c86473dc329bb58feddb82962ce1 by Nate Graham, on behalf of Natalie Clarius. Committed on 05/12/2023 at 16:53. Pushed by ngraham into branch 'master'. applets/battery: fix switch for manual inhibition falsely checked when inhibited by some other app FIXED-IN: 6.0 M +1 -0 applets/batterymonitor/package/contents/ui/PopupDialog.qml M +2 -1 applets/batterymonitor/package/contents/ui/PowerManagementItem.qml M +6 -4 applets/batterymonitor/package/contents/ui/logic.js M +3 -0 applets/batterymonitor/package/contents/ui/main.qml https://invent.kde.org/plasma/plasma-workspace/-/commit/feaa8903e809c86473dc329bb58feddb82962ce1
Git commit afdd04821febd8c2b6ad983977721b34db112db7 by Nate Graham, on behalf of Natalie Clarius. Committed on 05/12/2023 at 16:55. Pushed by ngraham into branch 'master'. applets/battery: show app inhibitions even when manually inhibited too It doesn't hurt to inform the user what other apps additionally hold inhibitions, we don't hide the others when there are multiple app inhibitions either, and it just adds complexity to the logic, so let's simply always show all active inhibitions. M +3 -8 applets/batterymonitor/package/contents/ui/PowerManagementItem.qml https://invent.kde.org/plasma/plasma-workspace/-/commit/afdd04821febd8c2b6ad983977721b34db112db7