Created attachment 9361 Fix inhibitor proxying When inhibiting the screensaver using e.g. xfce4-screensaver-command -q, xfce4-screensaver reports an error: [listener_add_ref_entry] gs-listener-dbus.c:566 (23:08:55.999): Adding inhibitor from Unknown for reason 'Unknown' on connection :1.180 [add_session_inhibit] gs-listener-dbus.c:535 (23:08:56.000): org.freedesktop.DBus.Error.ServiceUnknown raised: The name org.freedesktop.login1 was not provided by any .service files [listener_check_activation] gs-listener-dbus.c:308 (23:08:56.000): Checking for activation [list_ref_entry] gs-listener-dbus.c:275 (23:08:56.000): inhibitor: Unknown for reason: Unknown Consequently, there is indeed no inhibitor added to logind: [m@n:~] systemd-inhibit | grep xfce4-scr [m@n:~] This is due to the fact that src/gs-listener-dbus.c:add_session_inhibit() uses the wrong connection for the dbus message and thus expects logind on the session bus. After switching to the system connection, the inhibitor is correctly relayed and the error message disappears: [listener_add_ref_entry] gs-listener-dbus.c:566 (23:10:23.208): Adding inhibitor from Unknown for reason 'Unknown' on connection :1.183 [listener_check_activation] gs-listener-dbus.c:308 (23:10:23.215): Checking for activation [list_ref_entry] gs-listener-dbus.c:275 (23:10:23.215): inhibitor: Unknown for reason: Unknown [m@n:~] systemd-inhibit | grep xfce4-scr Unknown 1000 m 638981 xfce4-screensav idle Unknown block [m@n:~] See attached patch for a fix that works for me.
Michael Weiser referenced this bugreport in commit a9d0eb923bb379ad2b4767d09fde6e87577c46cd Fix inhibitor proxying (bug #16356) https://git.xfce.org/apps/xfce4-screensaver/commit?id=a9d0eb923bb379ad2b4767d09fde6e87577c46cd
You are on a roll with these patches! Applied above.
Thanks for reviewing and applying! With these fixes, vlc (with a fixed version of the patch from https://trac.videolan.org/vlc/ticket/9718) and firefox (custom patch I'm carrying locally) can now use the xfpm dbus interface to reliably inhibit DPMS and screen saving and locking. I started this because suspending the screen saver did not work from firefox because it falls back to just XScreenSaverSuspend if neither org.freedesktop.ScreenSaver nor org.gnome.SessionManager are available, which even if it worked would still leave DPMS coming on after its timeout. I would like to try and push patches upstream for vlc, firefox and maybe xdg-screensaver to use the xfce4-power-manager org.freedesktop.PowerManagement interface to inhibit both DPMS and xfss now it's working. But since both xfpm and xfss were already offering these interfaces in a non-working state I'm wondering how long I should wait for the xfss/xfpm fixes to reach users (applications will likely refuse heuristics trying to distinguish a broken org.freedesktop.PowerManagement from a working org.freedesktop.PowerManagement - if that's even possible). If the fixes were coming with the next XFCE release, I would target around two to three years optimistically for everyone having updated. With backporting the fixes, it could be less, I guess. So long story short: - Do you plan to backport the fixes to previous XFCE releases (including the fix for xfpm from https://bugzilla.xfce.org/show_bug.cgi?id=16364) and if so to which? Is that even necessary or can 4.14 and 4.12 users upgrade to the latest xfss and xfpm? - What would you recommend approach- and grace-period-wise? From what I gather the dbus way would be to increment the interface version. org.freedesktop.PowerManagement would become org.freedesktop.PowerManagement2 and org.xfce.ScreenSaver org.xfce.ScreenSaver2. But that would require all clients which were successfully using other aspects of those interfaces until now to update the interface name and implement a fallback to the old one if it's not available. Or xfpm and xfss would need to serve both names each. I don't know what the best practice is there.
Huh, overlooked https://bugzilla.xfce.org/show_bug.cgi?id=16368 which is still pending, so it's more of a what-if discussion still.