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

List:       kde-devel
Subject:    Re: Locking screen *before* suspend?
From:       Jeffery MacEachern <j.maceachern () gmail ! com>
Date:       2010-07-06 21:50:18
Message-ID: AANLkTimecMK1hjREjYwYZAGsGtPq8FxiT0nQGRCrYmk7 () mail ! gmail ! com
[Download RAW message or body]

On Tue, Jul 6, 2010 at 2:43 PM, Joanna Rutkowska
<joanna@invisiblethingslab.com> wrote:
> 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)?

Just to clarify, I meant that the only unambiguous evidence of the
screen being locked versus just being blanked (as in suspend) is the
Unlock dialog itself, so while my understanding (I don't claim to be
certain) is that it does lock entirely beforehand, it might not be
apparent.  I've seen the bug you have described happen occasionally
even when locking the screen without suspending, and my point was that
maybe you weren't seeing it lock before suspend because of the
parameters of your computer, and then on resume it looked like it was
locking afterward.
    - Jeffery MacEachern

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

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