On Sunday 27 of October 2013 02:45:54 Sl�vek Banko wrote:
> On Saturday 26 of October 2013 19:17:37 Darrell Anderson wrote:
> > >while investigating the problem, when autosuspend in TDEpowersave
> > >as well as
> > >change the suspend state in response to pressing a suspend/power
> > >button hangs
> > >when the screen saver is active, I found that SaverEngine never
> > >reached
> > >Saving state. Lock process not correctly sent a signal on fully
> > >activation
> > >back to SaverEngine. For this reason, SaverEngine may behave
> > >incorrectly in
> > >different situations.
> > >
> > >I fixed this in commit cbbc7ad0 (tdebase).
> > >
> > >Please test the correct behavior of screen saver.
> >
> > What steps are required to test?
> >
> > Darrell
>
> To test the problem, which was fixed, it is simple:
> 1) Make sure that you have enabled lock screen before suspend or standby.
> 2) Set the screen saver run after a short time.
> 3) Once the screensaver is activated, press button to go into suspend mode.
> Or set in tdepowersave autosuspend for a short time => a little longer than
> time to activate screen saver.
> 4) Look, that nothing happens (for any length of time), until you cause an
> activity that will lead to stop screen saver.
> 5) Only after stopping screen saver follows immediately switch into desired
> suspend mode.
>
> My call to test the behavior of the screen saver but refers to the general
> test the correctness of the behavior of screen saver after my fix. Before
> fix SaverEngine was never reached mode "Saving", but always constantly only
> in a state "Waiting." The code that should be executed in mode "Saving" for
> a long time has never been performed. And that is why I called for a
> general test.
>
> Slavek
>

As I now noticed a problem with the necessity of user input (for interrupt the 
screen saver) you reported also in the bug report 1615. It is possible that 
bug fixed in commit cbbc7ad0 could be related also with NFS on /home?

Can you try it?

Slavek
--