From kde-devel Wed Jul 07 09:36:37 2010 From: Dario Freddi Date: Wed, 07 Jul 2010 09:36:37 +0000 To: kde-devel Subject: Re: Locking screen *before* suspend? Message-Id: <4C344AA5.7020206 () gmail ! com> X-MARC-Message: https://marc.info/?l=kde-devel&m=127849543331933 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0400927658==" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0400927658== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig62E7C6392CCB6D94A3169CDD" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig62E7C6392CCB6D94A3169CDD Content-Type: multipart/alternative; boundary="------------020406010209070407060600" This is a multi-part message in MIME format. --------------020406010209070407060600 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/07/2010 12:32, Joanna Rutkowska wrote: > On 07/06/10 11:39, Miha =C4=8Can=C4=8Dula wrote: >> 2010/7/6 Joanna Rutkowska >> >>> 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 resum= e >>>>> 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 after= wards >>>>> the screen gets locked and the unlock password is expected. >>>> IMO, the screen *is* locked before suspending. That you get to see t= he >>> desktop >>>> for a short time is a compositing error. >>>> >>> Hmmm, but I sometimes see this problem even with composition disabled= =2E.. >>> >>> 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, i= sn'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 i= s > clearly a bug that I see the screen on resume, The screen is always locked before suspending, also because there's no way to lock the screen afterwards, as we don't get any signaling upon resuming. This is a known problem with the screen locker which is also reproducible with the screensaver, IIRC. > 2) Confirmation that the screen is locked *after* resume, and > explanation why this is done so this way. > > joanna. > > > > =20 >>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubsc= ribe << --------------020406010209070407060600 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/07/2010 12:32, Joanna Rutkowska wrote:
On 07/06/10 11:39, Miha =C4=8Can=C4=8Dula wrote:
2010/7/6 Joanna Rutkowska <joanna@invis=
iblethingslab.com>

On 07/05/10 20:29, Stefan Majewsky wrote:
On Monday 05 July 2010 12:12:05 Joanna Rutkows=
ka wrote:
It seems like KDE locks screen (via kscreenl=
ocker) 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, bu=
t 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,

The screen is always locked before suspending, also because there's no way to lock the screen afterwards, as we don't get any signaling upon resuming.

This is a known problem with the screen locker which is also reproducible with the screensaver, IIRC.

2) Confirmation that the screen is locked *after* resume, and
explanation why this is done so this way.

joanna.

=20
Visit http://mail.kde.or=
g/mailman/listinfo/kde-devel#unsub to unsubscribe <<

--------------020406010209070407060600-- --------------enig62E7C6392CCB6D94A3169CDD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkw0SrEACgkQaqeZcVEamjuEEwCcDYoxc6XzS/VyMZ1EWoysJMep m8kAnj+boPgHZ14udtz5X19XHfR0DO1T =B6m4 -----END PGP SIGNATURE----- --------------enig62E7C6392CCB6D94A3169CDD-- --===============0400927658== 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 << --===============0400927658==--