Review Request 117091: Force the screen locker's greeter to show the password input field in case of immediateLock

Wolfgang Bauer wbauer at tmo.at
Thu Mar 27 13:10:39 GMT 2014



> 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

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


-----------------------------------------------------------
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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20140327/49d2a3e4/attachment.htm>


More information about the kde-core-devel mailing list