I am running xfce4 version 4.8.0.2 with all its bell and whistles (including XFPM version 1.0.11) in Debian 7 (wheezy). The installation includes xscreensaver, which I don't mind using. I am reporting a problem where XFPM and xscreensaver have disagreement on the DPMS parameters. Each software has its own store of DPMS parameters (i.e. whether DPMS is enabled, and the timeout values for Standby, Suspend, and Off). XFPM stores the settings in the XFCE setting registry, where xscreensaver stores its parameters in ~/.xscreensaver file. If I set, say, the DPMS "Off" timeout value that is different in both software, then it is not clear who will give the last word. You can observe this issue by alternating the invocation of xscreensaver-demo and XFPM setting dialog. Whichever tool is invoked for the last time, that's what eventually sets the DPMS settings. (I use "xset q" to check the applied DPMS parameters in the X server.) But this is not the whole story. In XFPM settings dialog, if the timeout values are not changed (ie. the values are the same upon closing the dialog box), then no changes were done on the X DPMS settings, so in the end XFPM set of values did not get applied upon closing the dialog box. I also post this problem here (post #3) http://forum.xfce.org/viewtopic.php?pid=30157#p30157 Here's my proposal: *) since XFPM is supposed to be an upper-level tool, it may be necessary to make XFPM to override the settings of xscreensaver, too, to be consistent. Say, if a user changes the XFPM DPMS timeout settings, the new values are propagated to ~/.xscreensaver (if that program is running). The problem becomes more interesting with reading-in the XFPM values. Do we need to let XFPM read from ~/.xscreensaver too? *) Alternatively, in both XFPM and xscreensaver there should be an option which basically is: "don't mess with the X DPMS settings", as suggested by these bug reports: https://bugzilla.xfce.org/show_bug.cgi?id=6595 https://bugzilla.xfce.org/show_bug.cgi?id=10192 In this case, we can let XFPM handle all the DPMS settings, and not allow xscreensaver to mess with any. Or vice versa if the user wants it. Let me know what you think. Wirawan
Well as you correctly pointed out, XScreenSaver uses its own DPMS settings and ignores the settings of the Xserver. The power manager instead uses the Xserver's DPMS interface, so the two can never really correspond. So this really isn't a bug in xfce4-power-manager. However, we might in a future version of xfpm include a tab to handle screensavers/lockscreens, where the user can select which software he wants to handle the locking. When XScreenSaver would be selected there, we could make all the DPMS and blanking related controls insensitive so that the settings can only be edited in XScreenSaver's own settings UI. But that's about everything that can be done about this bug imo. Making xfpm override XScreenSaver's settings isn't really possible afaik.
While I agree this may not be an XFPM bug /per se/, it is an XFCE compilation bug in my view since XFPM and xfce4-session both place .desktop files in /etc/xdg/autostart for xfpm and xscreensaver respectively, and both of those apps compete against each other to set dpms settings. I think there needs to be better autodetection in xfpm to see if xscreensaver exists, and disable certain features if xscreensaver provides them. My machine is a desktop and does not require ACPI-related power management facilities provided by XFPM and so on my machine I simply disable XFPM by removing the .desktop file from /etc/xdg/autostart as I am happy with the screenblanking and DPMS settings offered by xscreensaver alone. But that will not be feasible for laptop computers, for example, that require some mix of features (screenblanking, dpms and ACPI-related power management).
Or Xscreensaver could be changed to be nicer with DPMS, but the developer seems to be reluctant: https://bugs.launchpad.net/ubuntu/+source/xscreensaver/+bug/924278