! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Inhibitor not proxied to logind


Description Michael Weiser 2020-01-08 23:14:14 CET
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

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

See attached patch for a fix that works for me.
Comment 1 Git Bot editbugs 2020-01-15 11:41:18 CET
Michael Weiser referenced this bugreport in commit a9d0eb923bb379ad2b4767d09fde6e87577c46cd

Fix inhibitor proxying (bug #16356)

Comment 2 Sean Davis editbugs 2020-01-15 11:41:42 CET
You are on a roll with these patches! Applied above.
Comment 3 Michael Weiser 2020-01-15 12:56:20 CET
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.
Comment 4 Michael Weiser 2020-01-15 12:58:09 CET
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.

Bug #16356

Reported by:
Michael Weiser
Reported on: 2020-01-08
Last modified on: 2020-01-15


Sean Davis
CC List:
0 users



Fix inhibitor proxying (1.43 KB, patch)
2020-01-08 23:14 CET , Michael Weiser
no flags

Additional information