Bug 310871 - Screen always locks (requires password) even if not supposed to
Summary: Screen always locks (requires password) even if not supposed to
Status: RESOLVED FIXED
Alias: None
Product: kscreensaver
Classification: Unmaintained
Component: locker-qml (show other bugs)
Version: 4.9.80 Beta1
Platform: openSUSE Linux
: NOR major
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords: regression
: 309702 311434 311596 311626 312833 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-11-29 12:26 UTC by bill p. (aka google01103)
Modified: 2013-12-15 07:52 UTC (History)
19 users (show)

See Also:
Latest Commit: http://commits.kde.org/kde-workspace/72ca24bb6484b014ea4d91a323b8a7c8a44085aa
Version Fixed In: 4.10.1
Sentry Crash Report:

Attachments
Patch for smoothing (956 bytes, patch)
2013-05-07 11:59 UTC, Hrvoje Senjan 		Details
View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description bill p. (aka google01103) 2012-11-29 12:26:31 UTC 
this is for 4.9.80 (4.10beta1) running on a desktop

session always locks, it did not in 4.9.3
screen saver does not lock (as it is config'ed to not to) 
power powerdevilrc has configLockScreen=false

kscreensaverrc:
Code: Select all
[ScreenSaver]
Enabled=true
LegacySaverEnabled=true
Lock=false
LockGrace=60000
PlasmaEnabled=false
Saver=KClock.desktop
Timeout=600

Reproducible: Always

Steps to Reproduce:
1. leave pc unsused
2. wait until after screensaver stops and monitor is blank
3. hit any key and password is required to return to session
Actual Results:  
screen is locked

Expected Results:  
password is not required to return to session

I assume that running 4.10beta1 that the locker is the qml version
Comment 1 Aaron J. Seigo 2012-11-29 21:23:23 UTC 
indeed, the password dialog is always started / shown no matter the setting.
Comment 2 bill p. (aka google01103) 2012-11-29 22:12:07 UTC 
also the password field should be focused, currently it needs to be selected
Comment 3 Simple 2012-11-30 15:09:11 UTC 
Just to re-enforce that the password filed does not get focused but i dont know it it would be better to create a different bug report or if it can be handled here.
Some feedback would be appreciated.
Comment 4 bill p. (aka google01103) 2012-12-04 22:44:46 UTC 
not fixed in beta2
Comment 5 Jekyll Wu 2012-12-09 21:09:52 UTC 
*** Bug 311434 has been marked as a duplicate of this bug. ***
Comment 6 Mark Fraser 2012-12-10 15:48:34 UTC 
A couple of other things I've noticed are that the password dialogue appears just before the screen saver starts up and if you move the mouse just after it has activated the screen saver crashes.
Comment 7 Anne-Marie Mahfouf 2012-12-11 09:27:12 UTC 
Confirmed in KDE 4.10 beta2, marking as regression.
Comment 8 Jekyll Wu 2012-12-13 00:28:23 UTC 
*** Bug 311596 has been marked as a duplicate of this bug. ***
Comment 9 bill p. (aka google01103) 2012-12-28 17:28:26 UTC 
still occurring and as we are in 4.10rc1, will this be resolved by final?
Comment 10 Jaime Torres 2013-01-11 15:19:34 UTC 
*** Bug 309702 has been marked as a duplicate of this bug. ***
Comment 11 Oliver Henshaw 2013-01-11 21:10:51 UTC 
KSldApp needs to be taught to respect the Lock boolean from kscreensaverrc - if the screenlocker is set not to require a password then the grace period should extend indefinitely.

It's not quite as simple as I first thought though: in the new locker is looks like the grace period is only meant to start when the screenlocker is activated on idle, not in other situations (may not be a conscious design choice though). I need to check how the old screensaver locker acted in various situations to see what the correct behaviour is.
Comment 12 Oliver Henshaw 2013-02-02 17:23:15 UTC 
This is https://git.reviewboard.kde.org/r/108425/
Comment 13 Kay Simon 2013-02-06 14:10:14 UTC 
Still occurring in 4.10 Final, did anybody noticed about it?
Comment 14 jef_pera 2013-02-06 16:11:23 UTC 
Yes, this annoying bug is still present in 4.10 final.
However I just applied Oliver Henshaw's patch and it works.
Comment 15 Oliver Henshaw 2013-02-11 17:34:24 UTC 
Git commit 72ca24bb6484b014ea4d91a323b8a7c8a44085aa by Oliver Henshaw.
Committed on 11/01/2013 at 21:04.
Pushed by oliverhenshaw into branch 'KDE/4.10'.

Respect Lock boolean in configuration

If not set to require password, don't start the grace period timer and
always consider in grace period.

REVIEW: 108425
FIXED-IN: 4.10.1

M  +7    -1    ksmserver/screenlocker/ksldapp.cpp

http://commits.kde.org/kde-workspace/72ca24bb6484b014ea4d91a323b8a7c8a44085aa
Comment 16 Christoph Feck 2013-02-19 00:36:45 UTC 
*** Bug 312833 has been marked as a duplicate of this bug. ***
Comment 17 bill p. (aka google01103) 2013-02-19 19:51:50 UTC 
latest update to 4.10 appears to have fixed this
Comment 18 Baokai Lei 2013-03-09 18:47:05 UTC 
I've updated to 4.10.1, and the "password is always required" issue is indeed fixed. You do no longer have to enter your password, if you didn't check that option.

However, there are still a few issues remaining unchanged in 4.10.1 (I already wrote about them in my bug report here: https://bugs.kde.org/show_bug.cgi?id=312833)

- When the timeout for the screensaver is up and the screensaver is launched, the screen lock dialog is *still* displayed (with the 4.10 default wallpaper as background), with the screensaver running on top of it. The screenlock dialog should only be displayed when the "password required" option has been checked.

- The very first time the screensaver is launched by timeout after a session has been started, the screensaver crashes, and you're left with only the 4.10 default wallpaper and the screen lock dialog on top of it. All consecutive times the screensaver is launched by timeout, it runs properly.

- The 4.10 default wallpaper (found here: /usr/share/wallpapers/Elarun/contents/images/) is only avaiable in 2560x1600. It is not scaled down properly to my resolution (1920x1200) when used as the background, making it look very jaggy. You should use a smooth scaling method here.

- When the screensaver is launched, the mouse cursor is still visible. It should be hidden.

I'm using the kslideshow screensaver, if that is of any importance.
Comment 19 Gordon 2013-03-24 13:55:51 UTC 
This bug is NOT fixed.

I am seeing the same behavior in 4.10.1 as reported by Baokai Lei.   That is, while the password is no longer required, the screen lock password dialog is still displayed with the screensaver running on top of it and the screenlock dialog should only be displayed when the "password required" option has been checked.  When the screensaver is awakened then the password dialog disappears such that the password is not required, however, the dialog should never have been presented in the first place.

I am running the kcometen4 screensaver which uses the desktop as the basis for a cubed background.  However, because the password dialog is displayed, the 4.10 screenlock default wallpaper is erroneously used for the cubed background instead.

I am running KDE 4.10.1 on OpenSUSE 12.3.
Comment 20 Oliver Henshaw 2013-03-24 17:52:33 UTC 
(In reply to comment #19)
> This bug is NOT fixed.
> 
> I am seeing the same behavior in 4.10.1 as reported by Baokai Lei.   That
> is, while the password is no longer required, the screen lock password
> dialog is still displayed with the screensaver running on top of it and the
> screenlock dialog should only be displayed when the "password required"
> option has been checked.  When the screensaver is awakened then the password
> dialog disappears such that the password is not required, however, the
> dialog should never have been presented in the first place.

This is bug #315442 and bug #316296 - the unlock dialog is always displayed and the unlock dialog sits on top of the screensaver. The first problem is unnecessary and confusing and frustrating, but luckily only cosmetic; the second problem you can work around by dismissing the unlock dialog with the Escape key.

I had hoped to sort this out for 4.10.2, but that's not looking certain now. Sorry about this.
Comment 21 Oliver Henshaw 2013-04-18 15:42:03 UTC 
*** Bug 311626 has been marked as a duplicate of this bug. ***
Comment 22 Oliver Henshaw 2013-05-07 11:44:19 UTC 
(In reply to comment #18)
> However, there are still a few issues remaining unchanged in 4.10.1
Sorry, I've had a tab open with this bug for a while, nagging at me to reply to you.  Are there any other unreported bugs remaining apart from the ones you mention below?

> 
> - The very first time the screensaver is launched by timeout after a session
> has been started, the screensaver crashes, and you're left with only the
> 4.10 default wallpaper and the screen lock dialog on top of it. All
> consecutive times the screensaver is launched by timeout, it runs properly.
> 
> - The 4.10 default wallpaper (found here:
> /usr/share/wallpapers/Elarun/contents/images/) is only avaiable in
> 2560x1600. It is not scaled down properly to my resolution (1920x1200) when
> used as the background, making it look very jaggy. You should use a smooth
> scaling method here.

Can you file a bug for these two?

> 
> - When the screensaver is launched, the mouse cursor is still visible. It
> should be hidden.
Bug #316459
Comment 23 Hrvoje Senjan 2013-05-07 11:59:22 UTC 
Created attachment 79751 [details]
Patch for smoothing

@Oliver, i can commit this patch for smoothing if i get a green light from you. Or should i use reviewboard?
Comment 24 Oliver Henshaw 2013-05-07 13:01:36 UTC 
(In reply to comment #23)
> Created attachment 79751 [details]
> Patch for smoothing
Thanks!

> 
> @Oliver, i can commit this patch for smoothing if i get a green light from
> you. Or should i use reviewboard?

Use reviewboard: it's good practice, and it will reach people who are better suited to evaluate the patch than me. It looks good to me, but maybe there's some subtlety or better approach I'm not aware of.
Comment 25 Hrvoje Senjan 2013-05-07 19:40:37 UTC 
(In reply to comment #24)
> Use reviewboard: it's good practice, and it will reach people who are better
> suited to evaluate the patch than me. It looks good to me, but maybe there's
> some subtlety or better approach I'm not aware of.

Sure, just thought maybe this one is not worth the trouble, as it's a one-liner. 
Added now: https://git.reviewboard.kde.org/r/110350/