Power manager unable to lock screen while xflock4 can

changed the description

The same problem in Fedora 34 using xscreensaver.

"None of the screen lock tools ran successfully..."

It doesn't work with xscreensaver (=> "SCREENSAVER_TYPE_FREEDESKTOP") because the org.freedesktop.ScreenSaver dbus interface does not contain a Lock() method, only Inhibit() and UnInhibit() ... And light-locker (which does provide a lock-method) refuses to run with xscreensaver already active That's a seperate issue from the problem with cinnamon..

@giwiniswut bustle can be used to monitor the dbus session bus, maybe you can find further detail about what goes wrong on org.cinnamon.ScreenSaver..

As the fork-button is not available to me ("You have reached your project limit" even with 0 repos here) I can't open a PR right now, so here's a proposed patch to solve the locking when running with xscreensaver (#142 (comment 34631)).

fix-None-of-the-screen-lock-tools-ran-successfully-error.patch

Maybe you could ask for premission to fork and do merge requests in the xfce developers' mailing list? BTW why not make the xfce_screensaver_lock function even more simple by letting it lock by xflock4? It could help for xfce4-session#115 (closed), too.

@eMPee584 today i randomly decided to check in on this issue and noticed your message.

Thanks for the patch! I just compiled xfce4-power-manager from current sources + your patch applied and screen locking finally works as expected.

Okay after having a look with bustle i think this is what's going on with Cinnamon Screensaver:

xfce4-power-manager tries to call org.freedesktop.ScreenSaver.Lock which is present and provided by csd-screensaver-proxy (cinnamon settings daemon) according to d-feet. This returns a GDBus.Error:org.freedesktop.DBus.Error.NotSupported: This method is not implemented.
The actuall implementation of Lock() is at org.cinnamon.ScreenSaver.Lock - it is directly called by cinnamon-screensaver-command --lock
When running xfce4-power-manager compiled with your patch, bustle first logs the call to org.freedesktop.ScreenSaver.Lock erroring out and then logs the subsequent calls made by csd-screensaver-proxy once xfce4-power-manager falls back to the screensaver command from xfconf or to xflock4.

Okay so far so good. Does this mean that there is a bug in Cinnamon? I.E. the csd-screensaver-proxy could live up to its name, implement the org.freedesktop.ScreenSaver.Lock method in order to proxy any invocations towards /org/cinnamon/ScreenSaver

Edit: I can only find the idle-inhibit-spec on https://specifications.freedesktop.org so i guess that there is no official specification for org.freedesktop.ScreenSaver.Lock?

Edit2: The org.freedesktop.ScreenSaver interface provided by csd-screensaver-proxy behaves the same if i create a new user and only ever log in via a Cinnamon session. If the behavior is due to a misconfiguration on my part it would need to be on the system side of things, i might check with a distro that actively supports cinnamon.
Update 2022-08-28: On Linux Mint 21 Cinnamon calling org.freedesktop.ScreenSaver.Lock reprocuces the not implemented error.

Edit3: Okay Vanilla GNOME currently also does not implement things like Lock or SetActive on the org.freedesktop.ScreenSaver interface, probably adhering to the hard specifications. However, KDE Plasma does support locking the screen via org.freedesktop.ScreenSaver and years ago, someone suggested this in an issue for the MATE desktop.

I revisited this issue today and realized this bit:

The xfce4-power-manager has code to detect the D-Bus interfaces of various screensavers. The cinnamon-screensaver is part of this list so it should be supported, however, the xfce4-power-manager currently prioritises the interface at org.freedesktop.ScreenSaver if it is available. Since the cinnamon-screensaver provides both its specific interface and the one at org.freedesktop.ScreenSaver this trips up the xfce4-power-manager because the latter interface is incomplete. The same would probably happen for the org.gnome.ScreenSaver because the gnome screensaver also provides the org.freedesktop.ScreenSaver interface without proxying all of its methods.

Would it make sense to change the D-Bus interface detection code so that specific paths are prioritised if available?

Also, i've decided to open an issue over at cinnamon to find out what their devs think about the topic. https://github.com/linuxmint/cinnamon-settings-daemon/issues/373

To summarize i see these two issues:

If locking the screen via the D-Bus interface fails the xfce4-power-manager doesn't try to fall back to the user-specified command line.
The MR linked to this issue fixes this general problem.
The xfce4-power-manager has support for a number of specific screensaver D-Bus interfaces but prioritises org.freedesktop.ScreenSaver over most of them.
Screensavers which provide this interface without exposing all of their methods there as well won't work properly. This currently affects the Cinnamon and GNOME screensavers but presumable the MATE screensaver as well. There is currently no proposed patch that changes this behavior.

@giwiniswut , related: xfce4-session#149 (closed)

mentioned in issue #51 (moved)

added Patch label

mentioned in merge request !24 (closed)

mentioned in issue xfce4-session#149 (closed)

Had this problem too on Debian bookworm with xfce4-power-manager-4.18.0 and xscreensaver-6.02+dfsg1

Indeed, problem is that the D-Bus interface org.freedesktop.ScreenSaver does not actually have a method called Lock.

Developed this patch, then came here to submit it, but noticed this ticket already existed. So here is another patch that's smaller and simpler. I only moved one line:

diff --git a/src/xfce-screensaver.c b/src/xfce-screensaver.c
index c9d5c25a..9b7cdc85 100644
--- a/src/xfce-screensaver.c
+++ b/src/xfce-screensaver.c
@@ -505,7 +505,6 @@ xfce_screensaver_lock (XfceScreenSaver *saver)
 {
   switch (saver->priv->screensaver_type)
   {
-    case SCREENSAVER_TYPE_FREEDESKTOP:
     case SCREENSAVER_TYPE_MATE:
     case SCREENSAVER_TYPE_GNOME:
     case SCREENSAVER_TYPE_XFCE:
@@ -550,6 +549,7 @@ xfce_screensaver_lock (XfceScreenSaver *saver)
       }
       break;
     }
+    case SCREENSAVER_TYPE_FREEDESKTOP:
     case SCREENSAVER_TYPE_OTHER:
     {
       gboolean ret = FALSE;

Tested by compiling the modified xfce4-power-manager-4.18.0 package from source as described at https://www.linuxfordevices.com/tutorials/debian/build-packages-from-source

This moves the case conditional for SCREENSAVER_TYPE_FREEDESKTOPjust above that for SCREENSAVER_TYPE_OTHER, causing the power-manager to consider the D-Bus interface org.freedesktop.ScreenSaver after all the other D-Bus interfaces, and then to process it like SCREENSAVER_TYPE_OTHER thereby invoking xflock4.

Larger problem seems to be that the notion of what a D-Bus interface shape is supposed to be can be ambiguous and there is no official publishing, warning, or enforcement mechanism to catch attempts to use D-Bus interfaces incorrectly.

mentioned in merge request !31 (closed)

mentioned in merge request !32 (closed)

marked xfce4-session#115 (closed) as a duplicate of this issue

marked this issue as related to xfce4-session#115 (closed)

mentioned in issue xfce4-session#115 (closed)

marked this issue as related to #51 (moved)

marked #83 (closed) as a duplicate of this issue

marked this issue as related to #83 (closed)

mentioned in issue #83 (closed)

changed milestone to %4.18.1

assigned to @eMPee584

closed with commit 8b2578c0

mentioned in commit dd77cc0c

Thanks a lot to Marcel and everyone else involved in creating and releasing this patch and another thanks to everyone still working to sort out the remaining mess surrounding the issue!

I am still observing this problem with xfce4-power-manager version 4.19.1 and xscreensaver.

What are your versions of libxfce4ui and xfce4-session?

libxfce4ui: 4.18.4 xfce4-session: 4.18.3

It should work.

Can you describe more precisely what you do, what works and what doesn't?
Do you have any screensavers other than xscreensaver installed?

What is the output of

xfconf-query -c xfce4-session -p /general/LockCommand

Can you describe more precisely what you do

I would like my system to suspend after 15 minutes of inactivity. I am attaching a screenshot of my Power Manager settings.

what works

I can suspend my system using the xfce4-session-logout menu.

I can lock my system using xflock4.

and what doesn't?

After 15 minutes of inactivity, I get an error message, "None of the screen lock tools ran successfully", and my system doesn't suspend.

In a previous version of xfce4-power-manager, suspend after inactivity used to work.

Do you have any screensavers other than xscreensaver installed?

No.

What is the output of xfconf-query -c xfce4-session -p /general/LockCommand

That property is not set on my system.

As a test, I set it to xflock4:

xfconf-query -c xfce4-session -p /general/LockCommand -s "xflock4" --create -t string

However, after 15 minutes of inactivity, my system did not suspend and became unresponsive; many xflock4 instances were created and I had to reboot.

I can suspend my system using the xfce4-session-logout menu.

Are you talking about the dialog that opens when you run xfce4-session-logout in a terminal? If so it's very strange, because hibernating from the logout dialog or from xfce4-power-manager calls the same code to lock (the one from libxfce4ui).

However, after 15 minutes of inactivity, my system did not suspend and became unresponsive

Yes bad idea... this is fixed in xfce4-session 4.19.1 only, not in 4.18.x.

Does this help:

xfconf-query -c xfce4-session -p /general/LockCommand -s 'xscreensaver-command --lock'

Are you talking about the dialog that opens when you run xfce4-session-logout in a terminal? If so it's very strange, because hibernating from the logout dialog or from xfce4-power-manager calls the same code to lock (the one from libxfce4ui).

Yes, that's the dialog I mean. Using that dialog, suspend works and the screen is locked upon waking from suspend.

Does this help: xfconf-query -c xfce4-session -p /general/LockCommand -s 'xscreensaver-command --lock'

No, that did not help, I get the same None of the screen lock tools ran successfully error, and my system doesn't suspend.

Running the xscreensaver-command --lock command in a terminal locks the screen successfully though.

Yes bad idea... this is fixed in xfce4-session 4.19.1 only, not in 4.18.x.

I tried upgrading to xfce4-session 4.19.1, but this broke both xflock4 (nothing happens when running that command) and xscreensaver-command --lock (I get a xscreensaver-command: no screensaver is running on display :0.0 error), so I downgraded back to 4.18.3.

I get a xscreensaver-command: no screensaver is running on display :0.0 error

This is because we have removed the autostart launcher for xscreensaver in xfce4-session 4.19.1, you have to launch it yourself by some means at the beginning of the session (or your distribution has to add this launcher, or...).

No, that did not help, I get the same None of the screen lock tools ran successfully error, and my system doesn't suspend.

It's really weird, I suspect an installation and/or configuration problem on your side to be honest.

I suggest we don't spam this issue any longer and that you open a thread on the forum to debug this, I'll reply there: https://forum.xfce.org/index.php

I suggest we don't spam this issue any longer and that you open a thread on the forum to debug this, I'll reply there: https://forum.xfce.org/index.php

I created the thread: https://forum.xfce.org/viewtopic.php?pid=73134

Power manager unable to lock screen while xflock4 can

Designs

Child items ...

Activity