Introspection with d-feet and this old email post: https://lists.freedesktop.org/archives/xdg/2007-March/009187.html indicate that the Lock, Cycle, and SimulateUserActivity of dbus ScreenSaver services return (nothing) However, xfce_screensaver_lock() requires a return value. This results in failures to lock the screen before system suspend, for example. After removing the requirement for a return value, I found that the system would lock before suspend, but would not suspend until after it had been unlocked. The org.mate.ScreenSaver Lock service appears to block. At this point I disabled the logic that attempts to invoke the dbus locking services, so XFCE falls back on xflock4 and xdg-screensaver scripts, which are known to work and can be modified without access to source code in case they do not. That "fixed" the problem. Given the poorly spec'd DBUS services, I would suggest that setting: xfconf-query -c xfce4-session -p /general/LockCommand -s "somthing" --create -t string Should prevent powermanager from trying the dbus services first. If the settings indicate how the user wishes to lock the screen, try that method first. Actually, I'd suggest trying the scripts before the DBUS methods, as the scripts are already used in other contexts. What advantage do the DBUS services give here?
-- GitLab Migration Automatic Message -- This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfce4-power-manager/-/issues/51. Please create an account or use an existing account on one of our supported OAuth providers. If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev