Bug 258281

Summary: xscreensaver jumps the gun and locks the screen even when active
Product: [Fedora] Fedora Reporter: Valdis Kletnieks <valdis.kletnieks>
Component: xorg-x11-serverAssignee: X/OpenGL Maintenance List <xgl-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: medium    
Version: rawhideCC: mcepl, mtasaka
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-08-29 17:11:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Valdis Kletnieks 2007-08-27 21:56:10 UTC
Description of problem:
I have "blank after 2 minutes", "lock after 4 minutes" set in the xscreensaver
config.  All the same, it has been *often* disregarding these numbers - the
screen will go to lock *immediately*, rather than to "blank".  Or it will blank,
I'll move the mouse, it will unblank - and then 10 or 15 seconds later blank
again.  (By "often", I mean "several dozen times already today).  And most of
the time, I *know* there's activity going on (and yes, I'm aware of the X brain
damage where "mouse keypress don't show as activity" - this has been with mouse
motion and typing as well).

Version-Release number of selected component (if applicable):
xscreensaver-base-5.02-3.fc8.1

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
xscreensaver-base-5.02-3 was OK - something apparently got broken in the mass
rebuild.

Comment 1 Mamoru TASAKA 2007-08-28 03:10:38 UTC
Well, cannot reproducible on my i386 machine...

I guess there is something wrong with X module components, however
would you attach what
-----------------------------------------------------
xscreensaver -verbose -no-capture-stderr
-----------------------------------------------------
shows?

Comment 2 Valdis Kletnieks 2007-08-28 13:55:39 UTC
Looks like I pointed the blame in the wrong direction - looks like it's actually
an issue in the X server itself causing the xscrensaver extension to fire:

% xset s
...
Screen Saver:
  prefer blanking:  yes    allow exposures:  yes
  timeout:  0    cycle:  0

Zeros can't be good there.  I found this when I killed off xscreensaver and I
was *still* seeing the screen blank 10-15 seconds after I stopped typing.  Not
sure if it's an libxcb problem or a xorg-Xserver problem.

Comment 3 Mamoru TASAKA 2007-08-28 14:14:44 UTC
Thank you for information.

Then it should be better that we ask X maintainers for help.

Comment 4 Matěj Cepl 2007-08-28 16:53:27 UTC
Thanks for the bug report.  We have reviewed the information you have provided
above, and there is some additional information we require that will be helpful
in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf) and X server log
file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file
attachments using the bugzilla file attachment link below.

Could you please also try to run without any /etc/X11/xorg.conf whatsoever and
let X11 autodetect your display and video card? Attach to this bug
/var/log/Xorg.0.log from this attempt as well, please.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.


Comment 5 Valdis Kletnieks 2007-08-29 17:11:34 UTC
I tracked this down, it was a more fundemental issue with timekeeping - glibc's
gettimeofday() vdso support borked out on the kernel I was running. Basically,
the system time was off by 4096 seconds, so xscreensaver and the X server's idle
detection kept breaking because it would alternately check different things and
see over an hour's difference in timestamps.  So of course it broke because
timekeeping was totally busticated.  I've opened bug #264301 and will close this
bug as a dup of it...

*** This bug has been marked as a duplicate of 264301 ***