Hi,

There are several situations in which screensaver doesn't do the right
thing.

1) The monitor's power is often left on even when the screen is blanked.

2) It seems that notifications from Gajim, Psi, etc. will cause the
screen to re-awaken.

3) When moving the mouse or pressing a key to wake up the screen and
unlock it, frequently the previous content of the screen will show up
for a few seconds before it is blanked and the logic box shown.

The DE in use here is XFCE and the WM is XMonad.

In the Screensaver Preferences, it is configured as follows:

Mode: Blank screen only
Blank after 10 minutes
Cycle after 10 minutes
Lock screen after 0 minutes

Advanced tab -

Power management enabled
Standby after 10 minutes
Suspend after 15 minutes
Off after 18 minutes
Quick power-off in blank only mode enabled


Fade to black when blanking checked
Fade from black when unblanking not checked
Fade duration 8 seconds

XFCE configuration

Handle display power management checked
Blank after 10 minutes
Sleep after 11 minutes
Off after 15 minutes


It is unclear to me how these interact.

John

There is no way to fix this, because X11 sucks. http://www.jwz.org/xscreensaver/faq.html#hysteresis

But maybe you mean this: http://www.jwz.org/xscreensaver/faq.html#popup-windows

That's because your machine was suspended -- CPU halted -- and what you are seeing on the screen when it powers back on was put there by BIOS before the CPU started running again. It halted the CPU with the screen not-yet-blanked, from xscreensaver's perspective. Likewise, there is no way to fix this, because Linux sucks.

There is no way to fix this, because X11 sucks. http://www.jwz.org/xscreensaver/faq.html#hysteresis

But maybe you mean this: http://www.jwz.org/xscreensaver/faq.html#popup-windows

That's because your machine was suspended -- CPU halted -- and what you are seeing on the screen when it powers back on was put there by BIOS before the CPU started running again. It halted the CPU with the screen not-yet-blanked, from xscreensaver's perspective. Likewise, there is no way to fix this, because Linux sucks.

Where I have seen this, and bug reports thereof, the reason has been
race conditions in the suspend scripts, that allow the hardware
suspend to take place before xscreensaver has blanked the screen.
Typically because someone had the idea of adding & to all commands to
speed up the suspend sequence, and no "wait". I don't see why this
cannot be fixed, Linux or not.

Tormod

Hi JWZ.  Very nice to hear from you.

I am quite sure it's not just that the mouse is getting bumped, because
I have observed that the monitor will not enter power-saving mode at all
for days, and then after a reboot, it will work again.
Well, both; the monitor powers on and shows those boxes.  (Or, hmm,
perhaps it wasn't powered off in the first place?  I should try to get
some data on that...)
You know, that is possibly the case indeed.  Thanks.

Thanks for xscreensaver (and Netscape, and XEmace, while I'm at it.)

John

Hi JWZ.  Very nice to hear from you.

I am quite sure it's not just that the mouse is getting bumped, because
I have observed that the monitor will not enter power-saving mode at all
for days, and then after a reboot, it will work again.
Well, both; the monitor powers on and shows those boxes.  (Or, hmm,
perhaps it wasn't powered off in the first place?  I should try to get
some data on that...)
You know, that is possibly the case indeed.  Thanks.

Thanks for xscreensaver (and Netscape, and XEmace, while I'm at it.)

John

What packages do you think I ought to investigate?

Huh. Well, run it with -log for a few days and see what shows up. You will see a line when xscreensaver notices that the monitor has powered down. If it thinks it's still powered down, it won't launch hacks. The only time xscreensaver explicitly powers on the monitor is when unblanking the screen or displaying the unlock dialog. And even in those situations, it should time out and power off again eventually.

Possibly some other app is messing with your DPMS settings, or turning the monitor back on. The "notifications" thing you're seeing suggests that that might be happening.

Thanks, glad you like it!

I'm trying to run it under -log with -verbose, but it's complicated by
two things:

1) no date stamps with the timestamps (sometimes these things only
manifest themselves after awhile)

2) it doesn't seem to be calling fflush() on the log file after each
write, so tailing it doesn't necessarily show the most current information.

and a third thing, which is that it is highly intermittent.

I'll try to grab some time to investigate further while it's exhibiting
the issue as well.

Thanks,

John

Here is a section of xscreensaver.log.  The screen had been on but
black.  The activity at 17:56 was when I moved the mouse to wake it up,
but it had been on all day despite the room being vacant.

xscreensaver: 21:02:54: user is active (keyboard activity)
xscreensaver: 21:02:54: unblanking screen at Sat Nov 29 21:02:54 2014.
xscreensaver: 21:02:54: 0: ungrabbing mouse (was 0xaa).
xscreensaver: 21:02:54: 0: ungrabbing keyboard (was 0xaa).
xscreensaver: 21:02:54: starting de-race timer (10 seconds.)
xscreensaver: 21:02:54: awaiting idleness.
xscreensaver: 21:03:04: de-race completed.
xscreensaver: 21:04:15: 0: screen change event received
xscreensaver: 21:04:15: 0: screen change event received
xscreensaver: 21:04:15: new layout:
xscreensaver: 21:04:15: WARNING: RANDR and Xinerama report different
xscreensaver: 21:04:15:                 screen layouts!  Believing RANDR.
xscreensaver: 21:04:15: screens in use: 1
xscreensaver: 21:04:15:    3/0: 2560x1440+0+0 (DP2)
xscreensaver: 21:04:15: rejected screens: 4
xscreensaver: 21:04:15:    0/0: 1920x1080+0+0 (eDP1) -- enclosed by 3
(2560x1440+0+0)
xscreensaver: 21:04:15:    1/0: 1920x1080+0+0 (DP1) -- output disabled
xscreensaver: 21:04:15:    2/0: 1920x1080+0+0 (HDMI1) -- output disabled
xscreensaver: 21:04:15:    4/0: 1920x1080+0+0 (HDMI2) -- output disabled
xscreensaver: 21:04:15: 0: resize 0x2c00001 from 1920x1080+0+0 to
2560x1440+0+0
xscreensaver: 21:04:15: 0: screen change event received
xscreensaver: 21:04:16: 0: screen change event received
xscreensaver: 21:04:17: new layout:
xscreensaver: 21:04:17: WARNING: RANDR and Xinerama report different
xscreensaver: 21:04:17:                 screen layouts!  Believing RANDR.
xscreensaver: 21:04:17: screens in use: 1
xscreensaver: 21:04:17:    3/0: 2560x1440+0+0 (DP2)
xscreensaver: 21:04:17: rejected screens: 4
xscreensaver: 21:04:17:    0/0: 0x0+0+0 (eDP1) -- enclosed by 3
(2560x1440+0+0)
xscreensaver: 21:04:17:    1/0: 0x0+0+0 (DP1) -- output disabled
xscreensaver: 21:04:17:    2/0: 0x0+0+0 (HDMI1) -- output disabled
xscreensaver: 21:04:17:    4/0: 0x0+0+0 (HDMI2) -- output disabled
xscreensaver: 21:12:19: user is idle (timeout)
xscreensaver: 21:12:19: blanking screen at Sat Nov 29 21:12:19 2014.
xscreensaver: 21:12:19: 0: grabbing keyboard on 0xaa... GrabSuccess.
xscreensaver: 21:12:19: 0: grabbing mouse on 0xaa... GrabSuccess.
xscreensaver: 21:12:19: fading...
xscreensaver: 21:12:21: fading done.
xscreensaver: 21:13:18: disabling server builtin screensaver:
xscreensaver: 21:13:18:  (xset s 0 0; xset s blank; xset s expose)
xscreensaver: 21:23:21: timed out; activating lock.
xscreensaver: 21:23:21: 0: locked mode switching.
xscreensaver: 17:56:44: user is active (keyboard activity)
xscreensaver: 17:56:45: pam_start ("xscreensaver", "jgoerzen", ...) ==>
0 (Success)
xscreensaver: 17:56:45:   pam_set_item (p, PAM_TTY, ":0.0") ==> 0 (Success)
xscreensaver: 17:56:45:   pam_authenticate (...) ...
xscreensaver: 17:56:45:     pam_conversation (ECHO_OFF="Password: ") ...
xscreensaver: 17:56:45: 0: mouse is at 518,435.
xscreensaver: 17:56:45: 0: creating password dialog ("")
xscreensaver: 17:56:45: grabbing server...
xscreensaver: 17:56:45: 0: ungrabbing mouse (was 0xaa).
xscreensaver: 17:56:45: 0: grabbing mouse on 0x2c005b1... GrabSuccess.
xscreensaver: 17:56:45: ungrabbing server.
xscreensaver: 17:56:53: input finished.

Note - it does seen to have the correct screen to blank.

John

Well, there's nothing in there that looks obvious to me, though all of those "screen change" and "screen resize" event are suspicious. That may be unrelated, though.

Is there anything in the logs complaining about DPMS?

From the log you sent, it appears that the X server is, all by itself, deciding not to power off the monitor. I don't know why.

If you find a section of the log covering a time when the monitor had been powered off, and then powered back on, without you having made an attempt to unlock the screen, that might provide more of a clue.