This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============0676223919==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig151EA13D105E40031A8B838C"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig151EA13D105E40031A8B838C
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 =C4=8Can=C4=8Dula 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 resu=
me
>>>>>> from suspend (e.g. S3 sleep), which results in the original conten=
t of
>>>>>> the screen to be often visible for a second or more, and only afte=
rwards
>>>>>> 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 disable=
d...
>>>>
>>>> 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,
>=20
> 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?
>=20

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.


--------------enig151EA13D105E40031A8B838C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkwzo4EACgkQORdkotfEW86nNACeNu0rv5XPZZGMaEihomMzMMEL
mYIAoK0+8zqLsxSYKkAK3ySRlOrTP6uu
=qnBR
-----END PGP SIGNATURE-----

--------------enig151EA13D105E40031A8B838C--

--===============0676223919==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0676223919==--