kscreenlocker automatically uninhibits powerdevil if the inhibitor service unregisters itself. this is the case when using qdbus and dbus-send, causing xdg-screensaver suspend to not work correctly, which causes git mpv to not inhibit the screensaver. at least two previous bug reports have been opened on this issue, since (IMO) it is highly unexpected and user-unfriendly behavior. I think that kscreenlocker should be changed to not uninhibit when the caller is unregistered. I see the argument for avoiding hanging inhibitions, but bad applications can already call the powerdevil methods and forget to uninhibit. If hanging inhibitions is a serious issue, then a button can be added to the powerdevil widget to manually clear inhibitions. alternatively, the powerdevil methods should be changed to also check for caller unregistration (since presumably that would also be an issue), and some other way should be found for xdg-screensaver to operate (since currently, as mentioned before, xdg-screensaver suspend does nothing on KDE right now). as a potential use case, mpv would like to use xdg-screensaver or some shell-based method for inhibiting in order to avoid dbus dependencies in core code.
This is a violation of the Screensaver specification. If Mpv can't use DBus that's too bad. They could also keep a separate process running that does that.
(In reply to Kai Uwe Broulik from comment #1) > This is a violation of the Screensaver specification. If Mpv can't use DBus > that's too bad. They could also keep a separate process running that does > that. Hi, thank you for your response. I was unable to locate a "Screensaver specification", but read the "Idle Inhibition Service Draft" located at https://specifications.freedesktop.org/idle-inhibit-spec/0.1/, and could not identify any part that required the inhibitor application to keep the service registered. The only remotely relevant requirement appears to be that the screensaver application maintain "a well-known D-Bus name", which is obviously required in order to be located. I found no part requiring the inhibitor application to keep its service registered, merely an implication that it should keep track of its cookie. Moreover, this affects not only mpv, but all users of xdg-screensaver, whose suspend function does not work on KDE. How do you propose that be fixed? Do you say it should use org.freedesktop.PowerManagement.Inhibit instead? Why not fix kscreenlocker to meet the user expectations (as demonstrated in, now, three filed bugs)? In the alternative, if you argue that the current implementation is needed to maintain backwards-compatibility, or compatibility with Gnome, then the current behavior should at least be clearly documented somewhere in order to avoid apparent widespread user confusion.
We do not implement the idle-inhibit-spec. Also unlike claimed in the spec it was not develop in collaboration with KDE. We implement the screensaver spec which unfortuantely got deleted without any backups by gnome devs. So the only reference we have is our implementation. And given to that the xdg-screensaver application is just broken.
That is the spec we support. I think MG is referring to the power inhibitions protocol. which is different. Though from your own link click previous twice to see Chapter 3. > Inhibition will stop when the UnInhibit method is called, or the application disconnects from the D-Bus session bus (which usually happens upon exit).
Guess mpv won't work right on KDE then, pat yourselves on the back for your grand achievement.
oh yaeh sorry I mixed it up with powermanagement. Nevertheless I still think the spec looked differently in the past. @Nicolas: there is nothing we can do here. Our software works exactly as it should. The bug is with mpv and xdg-screensaver. If we would ignore the disconnect we would have other software breaking.