Bug 1475

I'm going to go out on a limb and guess that this is possibly related to Bug 1467.

(In reply to comment #1)
> I'm going to go out on a limb and guess that this is possibly related to Bug
> 1467.

I doubt it, bug #1467 appeared only after a dist-upgrade to the latest nightlies when I filed that bug. This particular bug has actually been around for quite awhile, I've just been neglecting to report it.

(In reply to comment #2)
> (In reply to comment #1)
> > I'm going to go out on a limb and guess that this is possibly related to Bug
> > 1467.
> 
> I doubt it, bug #1467 appeared only after a dist-upgrade to the latest
> nightlies when I filed that bug. This particular bug has actually been around
> for quite awhile, I've just been neglecting to report it.

Correction: I doubt it's related beyond the fact that you need to fix #1467 before fixing this (at least in the nightlies/git sources, 3.5.13-sru may be fixable if someone is still maintaining it)

No such problems I've noticed in 3.5.13.x. The only thing I accidentally saw
again recently, it was stuck kdesktop_lock in sigsuspend - as described in the
bug 1288. In this case, however, was not activated both - screen saver and also screen lock.

When observing a virtual machine but after a while I see a strange behavior:
While the screensaver is running properly, for a long time instead of screen
saver displays an background image (if it is turned on including the unlock
screen) - after a minute (my start saver time) saver starts again, runs 10
seconds and return to the background image. And so over and over again. The
time before it starts to behave strangely maybe corresponds to the time to
switch monitor to standby.

I have corrected several uninitialized variable issues in kdesktop_lock in my recent patches for Bug 1467; can you please re-test with those patches applied and let me know if they do anything to help this report?

Thanks!

(In reply to comment #4)
> No such problems I've noticed in 3.5.13.x. The only thing I accidentally saw
> again recently, it was stuck kdesktop_lock in sigsuspend - as described in the
> bug 1288. In this case, however, was not activated both - screen saver and also
> screen lock.

Perhaps it's specific to Debian Squeeze?

(Odpověď na komentář #6)
> (In reply to comment #4)
> > No such problems I've noticed in 3.5.13.x. The only thing I accidentally saw
> > again recently, it was stuck kdesktop_lock in sigsuspend - as described in the
> > bug 1288. In this case, however, was not activated both - screen saver and also
> > screen lock.
> 
> Perhaps it's specific to Debian Squeeze?

If I know Roman Savochenko uses a different distribution, and this problem also observed.

(Odpověď na komentář #4)
> When observing a virtual machine but after a while I see a strange behavior:
> While the screensaver is running properly, for a long time instead of screen
> saver displays an background image (if it is turned on including the unlock
> screen) - after a minute (my start saver time) saver starts again, runs 10
> seconds and return to the background image. And so over and over again. The
> time before it starts to behave strangely maybe corresponds to the time to
> switch monitor to standby.

I believe that the observed problem is related to the LockProcess::checkDPMSActive. After activation DPMS screen saver is stopped - it is very good. However, after a preset period of inactivity the screen saver is started again... and then was stopped again due to still active DPMS. And so over and over again.

(In reply to comment #8)
> I believe that the observed problem is related to the
> LockProcess::checkDPMSActive. After activation DPMS screen saver is stopped -
> it is very good. However, after a preset period of inactivity the screen saver
> is started again... and then was stopped again due to still active DPMS. And so
> over and over again.

Good work tracking this down!  I have committed several fixes to the DPMS handling code in GIT hash be61b99; please let me know if this resolves the problems noted.

(Odpověď na komentář #9)
> (In reply to comment #8)
> > I believe that the observed problem is related to the
> > LockProcess::checkDPMSActive. After activation DPMS screen saver is stopped -
> > it is very good. However, after a preset period of inactivity the screen saver
> > is started again... and then was stopped again due to still active DPMS. And so
> > over and over again.
> 
> Good work tracking this down!  I have committed several fixes to the DPMS
> handling code in GIT hash be61b99; please let me know if this resolves the
> problems noted.

Great, thank you, after activation DPMS screen saver now remains stopped.

(In reply to comment #10)
> Great, thank you, after activation DPMS screen saver now remains stopped.

So do the changes then resolve this bug report? :-)

Probably should wait until Kris (original reporter) tests the changes. :-)

(In reply to comment #12)
> Probably should wait until Kris (original reporter) tests the changes. :-)

OK, changing status to NEEDINFO.

On my test machine now noticing strange anomaly.
In .xsession-errors is repeatedly listed:

QTime::setHMS Invalid time 05:24:60.000

...and screensaver is not activated.

Where should I start researching?
The system time is in order.
Was the leap second?

Hmm, strange messages with time probably not related. When I tried using Ctrl + Alt + L to lock the screen, screen si successfully locked. And after that screen saver is working properly again.

Any progress on this?  Have the observed issues been resolved via the various GIT commits between the last bug report message and now?

Thanks!

The comments in this bug report awaiting further information or confirmation the patch resolved the problem are more than two months old. Should we close this report?

Yes.  The screensaver appears to work properly.