Summary: | Screen lock dialog is always displayed | ||
---|---|---|---|
Product: | [Unmaintained] kscreensaver | Reporter: | Baokai Lei <leibaokai> |
Component: | locker | Assignee: | kscreensaver bugs tracking <kscreensaver-bugs-null> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | bugs, kaysimon |
Priority: | NOR | ||
Version: | 4.9.98 RC3 | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Baokai Lei
2013-01-07 17:25:17 UTC
Just two more things: 1. To prevent misunderstandings: When the screensaver starts (or better, *should* start), the screen lock dialog doesn't appear *on top* of the screensaver, but *instead* of the screensaver, on a black screen. If I move the mouse shortly after it appears, the desktop returns without me having to enter the password. If I wait for a while before moving the mouse, I have to enter the password to unlock the screen and return to the desktop. It seems there's a grace period, but I have no idea how long it is. I haven't set up anything like that in the first place. 2. What I just noticed is that, after returning to the desktop, there's a yellow question mark in the system tray. Clicking on it, it told me that /usr/bin/kslideshow.kss crashed. It didn't present me with a crashlog, so I can't post it here. I tried it some more, and the yellow crash icon appears every time afterwards - I just didn't notice it before. Edit: It's a yellow exclamation mark, not a question mark. (Why can't you edit your comments here?) More precisely even, it's a black exlamation mark in a yellow jagged balloon. I've never seen this appear when a Kde application crashed. Just updated to 4.10 RC3 (4.9.98) and rebooted, but the bug is still the same. Further information: - If you don't have the option checked that a password is required to quit the screen saver, then you will need to enter a password right away when the screen lock dialog (with black background) appears. - If you *do* have the password required option checked however, it's different: -- When the timeout you've set there isn't up yet after the screen lock dialog appears, then the screen lock dialog will simply disappear again when you move the mouse, without having to enter anything. -- When the timeout from the password option is up, then moving the mouse won't do anything, and you'll have to enter the password normally to return to the desktop. However, when you move the mouse and do nothing otherwise, then the screen saver will run normally on top of the screen lock dialog after a very short pause (seems like one minute, much shorter than what is set for the screensaver timeout). When you *don't* move the mouse after the screen lock dialog comes up, then the screen saver will *never* run, and you'll always only have the screen lock dialog on a black background, regardless for how long (generally until the power saving options become active and turn off the screen). After a full update and reboot, I did another test now. Results were somewhat different now: I went to the screen lock settings dialog and unchecked the "password required after..." checkbox, to see if the error when it's unchecked is still the same (see above). What I found was: Once the timeout set for the screensaver is up, the screen lock dialog (on a black background) still appears, *but* the screen saver starts simultaneously with it now, and is drawn on top of it, hiding it eventually. The screensaver doesn't crash anymore! When you move the mouse after that, the desktop instantly appears, i.e. no password input required. Overall, a good improvement! Retried it, and it's reproducable. Rebooted (just in case), and it's still reproducible every time. What is left to do now is: - Don't show the screen lock dialog when the "password required" checkbox is unchecked. - Hide the mouse cursor! When the timeout was up and the screen lock dialog with the screen saver running on top of it appeared, the mouse cursor stayed visible all the time. Changed Importance from "crash" to "normal", as the screensaver doesn't crash anymore. Addendum: If the screen saver has been running for a while and you move the mouse, the screen lock dialog reappears, and you have to enter your password - even if the "password required" option is unchecked. So, regardless if the "password required" option is checked or not, after the screensaver has started, there is still a timeout (can't say how long) after which a password will be required. Updated to 4.10 final and rebooted. There's little change: - Once the timeout for the screensaver is up, the screen lock dialog still appears, but now, it has the nice 4.10 default wallpaper as background instead of a black background, which looks much better. However, the scaling of the image to my resolution (1920x1200) doesn't work properly, as the image appears quite jaggy. - The first time after a reboot or login, the screensaver crashes when the timeout is up, and you only have the screen lock dialog. On all consecutive times, the screensaver runs normally on top of the screen lock dialog. - Mouse cursor stays visible all the time. It should be hidden when the screensaver is running. - It's still completely ignored if you have the "password required" checkbox checked or not, and always behaves as if it's checked, so you'll *always* have to enter your password if the time given here has elapsed. - The maximum amount possible for the "password required" timeout is 300 seconds (5 minutes), which is *way* too short. First off, it makes no sense to have this in seconds, rather than minutes. Second, as this option is broken and you can't turn it off (same behaviour with it checked and unchecked), you'll *always* have to enter your password after a maximum of 5 minutes after the screensaver started, which is very annoying. If it allowed bigger time spans (like 1 or 2 hours), you could at least keep the required entering of your password to a bearable minimum. I confirm this in 4.10 final. Whether ~/.kde/share/config/kscreensaverrc contains Lock=true, Lock=false or no Lock line at all (which was the case after the upgrade from 4.9.5), the screen is locked after the screen save starts, plus the grace period (LockGrace in the rc file specifies the period in milliseconds). Duplicate of bug 310871 *** This bug has been marked as a duplicate of bug 310871 *** |