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

List:       kde-devel
Subject:    Re: Locking screen *before* suspend?
From:       Joanna Rutkowska <joanna () invisiblethingslab ! com>
Date:       2010-07-06 21:43:29
Message-ID: 4C33A381.1010603 () invisiblethingslab ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On 07/06/10 21:12, Jeffery MacEachern wrote:
> On Tue, Jul 6, 2010 at 3:32 AM, Joanna Rutkowska
> <joanna@invisiblethingslab.com> wrote:
>> On 07/06/10 11:39, Miha Čančula wrote:
>>> 2010/7/6 Joanna Rutkowska <joanna@invisiblethingslab.com>
>>>
>>>> On 07/05/10 20:29, Stefan Majewsky wrote:
>>>>> 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.
>>>>>
>>>> Hmmm, but I sometimes see this problem even with composition disabled...
>>>>
>>>> joanna.
>>>>
>>> I've noticed it too on Arch, so it does happen, but I usually have
>>> composting enabled and I can't say if this is the cause. Either way, isn't
>>> bugs.kde.org the place for this?
>>>
>> Before going to bugzilla, I was hoping to get either of the two:
>> 1) Confirmation that screen is locked *before* suspend, and that this is
>> clearly a bug that I see the screen on resume,
> 
> It looks to be, yes.  But depending on the laptop and the
> circumstances, it may not look like it.  For example, I've seen some
> machines that fully (visibly) lock before going to sleep, and then
> resume quickly, but some also go to sleep (apparently) instantly, and
> then resume more slowly; in that latter case, the bug you're seeing
> combined with the timing of the unlock dialog displaying could give
> the impression that it is actually locking after the resume.  Does
> that sound right?
> 

Can we do something about it? Like e.g. putting some wait-loop that
would ensure that the screenlocker has fully "owned" the screen, before
proceeding with the actual suspend (calling pm-suspend, which I guess is
what KDE finally does)?

joanna.


["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]