[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Locking screen *before* suspend?
From:       Dario Freddi <drf54321 () gmail ! com>
Date:       2010-07-07 17:37:15
Message-ID: 201007071937.21101.drf54321 () gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 07 July 2010 13:21:37 Joanna Rutkowska wrote:
> On 07/06/10 11:55, Olivier Goffart wrote:
> > Le Monday 05 July 2010, Stefan Majewsky a écrit :
> >> On Monday 05 July 2010 12:12:05 Joanna Rutkowska wrote:
> >>> It seems like KDE locks screen (via kscreenlocker) only after resume
> >>> from suspend (e.g. S3 sleep), which results in the original content of
> >>> the screen to be often visible for a second or more, and only
> >>> afterwards the screen gets locked and the unlock password is expected.
> >> 
> >> IMO, the screen *is* locked before suspending. That you get to see the
> >> desktop for a short time is a compositing error.
> > 
> > The problem seems that starting the screen saver is sometimes too slow
> > and we do not wait the screen saver has finished loading before going to
> > sleep.
> > 
> > Which mean that when the computer wakes up, the screen saver might still
> > not be running, and I can see the screen, and even interact with it for
> > few seconds. (Especially when the computer is on load)
> 
> This seems indeed the case. So, again, can we add a wait loop for the
> screenlocker to fully engage and only afterwards proceed with the suspend?

Patches welcome. But as I've already stated, I'm not sure this would fix the 
issue, as some people reported this problem even when the screensaver was 
triggered and the screen turned off afterwards.

Moreover, such a "waiting loop" is a bad hack, because there is currently no 
way (at least not something I'm aware of) to tell when the screenlocker has 
done its job, supposing your guess about kscreenlocker "not ready" was right. 

Although, if you manage to find out in a concrete way that this is the 
problem, what you want to do is fix this issue straight into kscreenlocker. 
Powerdevil currently calls Lock() on the screensaver's dbus interface in a 
synchronous way, which means that suspension does not take place until the 
method returns.

You ideally want to make Lock() return when the lock has been performed 
successfully, and have powerdevil make an asynchronous call on Lock(), 
starting the next action when Lock() has returned - this part is quite easy as 
it would need just an event loop in PowerDevilDaemon::lockScreen().

However, first you need to find out if this is the source of the issue - for 
example by adding a waiting loop of 5 seconds in lockScreen() and verify if 
the issue is still present - if so, please submit a patch to ReviewBoard or 
fill the existing bug (I'm quite sure there is one) with the needed 
information - but I can't guarantee I'll be able to take care of the issue 
soon, due to my limited free time these months.

P.S.: If it wasn't obvious, I cannot reproduce here. But I definitely could 
with my old nVidia-based laptop most of the times.

> 
> joanna.

-- 
-------------------

Dario Freddi
KDE Developer
GPG Key Signature: 511A9A3B

["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]