> On March 26, 2014, 11:07 p.m., Thomas Lübking wrote: > > you could sighup or sigusr the greeter process and have it > > > > setImmediateLock(true); > > desktopResized(); > > > > in return > > Wolfgang Bauer wrote: > I agree, this would be a bit nicer... > But I tried it and cannot get it to work. > > My signal handler is called, and both setImmediateLock(true) and > desktopResized() are called, (I verified this with debug output statements) > but the password dialog still doesn't show. > > > Wolfgang Bauer wrote: > Oops, sorry. I just noticed that the signal handler is apparently only > called when I run kscreenlocker_greet manually (and do "kill -USR1"), but not > when the locker runs it. > Will have to investigate this.
Forget my previous comment. The signal handler was actually called all the time. But "setImmediateLock(true);" followed by "desktopResized();" DOES NOT have any (visual) effect. I have yet to find out what else to call to make that dialog appear. Any idea maybe? Calling exit(1) does work, but that's not much different to killing the greeter I suppose... ;-) - Wolfgang ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117091/#review54247 ----------------------------------------------------------- On March 26, 2014, 5:58 p.m., Wolfgang Bauer wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/117091/ > ----------------------------------------------------------- > > (Updated March 26, 2014, 5:58 p.m.) > > > Review request for kde-workspace and Aaron J. Seigo. > > > Bugs: 327947 and 329076 > http://bugs.kde.org/show_bug.cgi?id=327947 > http://bugs.kde.org/show_bug.cgi?id=329076 > > > Repository: kde-workspace > > > Description > ------- > > If the screen locker is set to not require a password to unlock, it will not > show the password input field even when the powermanagement settings suspend > the system and are set to require a password after resume (when it was > already running at that point). > This locks people out of their system. > > As there seems to be no way to switch the already running greeter to > immediateLock mode, it is killed in that case by this patch. It gets > restarted immediately with the --immediatelock option in > KSldApp::lockProcessFinished() and shows the password input field then. > > > Diffs > ----- > > ksmserver/screenlocker/ksldapp.cpp 3dfcc9e > > Diff: https://git.reviewboard.kde.org/r/117091/diff/ > > > Testing > ------- > > Disable "Require password after" in the screen locker settings (the default), > set it to start after 1 min. (for easier testing). > Enable "Suspend session after" and set it to 2 minutes. (set the action to > "Suspend", "Hibernate", or "Lock Screen", doesn't matter) > Make sure "Lock screen on resume" is enabled in the powermanagements > "Advanced Options" (it is by default). > > After 1 minute the screen locker kicks in, and doesn't require a password. > After 2 minutes the session gets suspended, hibernated or locked, and > requires a password to resume. > > Without this patch no password dialog is shown, the user cannot resume the > session by entering the password. > > With this patch this works: there is a password input field, the session is > unlocked when the user enters the password. > > Other openSUSE users have tested this as well, see f.e. > https://bugzilla.novell.com/show_bug.cgi?id=864305#c4 > > > Thanks, > > Wolfgang Bauer > >
