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

[Wolfgang Bauer]

> 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.
> 
> Wolfgang Bauer wrote:
>     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... ;-)
>
> 
> Thomas Lübking wrote:
>     Ahhh... me was too smart in the multiscreen code ;-)
>     the "for" loop in desktopResized() (which is relevant for the m_immediateLock handling) won't be entered since no screen changed.
>     
>     Instead you'd run
>     
>     for (int i = 0; i < desktop()->screenCount(); ++i) {
>        QDeclarativeProperty(m_views.at(i)->rootObject(), "locked").write(true);
>     }
>     
>     aside fixing the m_immediateLock value.
>     
>     Sorry for the false information.
> 
> Wolfgang Bauer wrote:
>     Ok, that works.
>     Thank you for the help! :-)
>     
>     Btw, I noticed that UnlockApp::setLockedPropertyOnViews() basically does the same, so I'm just calling that instead to avoid code duplication.
>     I have uploaded a new patch.
>
> 
> Christoph Feck wrote:
>     What is the status of this patch? Do we have someone (besides yourself), who has enough knowledge of the screen locker to approve it?

Well, this patch fixes the issue on all systems I tried (which is only 2).
It is also part of openSUSE's KDE 4.12/4.13 (actually kdebase4-workspace-4.11.8) packages since over a week.

I think this is a grave bug, and really would like to see this fixed in 4.11.9.

Added plasma now to the group of reviewers, maybe somebody there is willing to approve it...


- Wolfgang


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117091/#review54247
-----------------------------------------------------------


On April 22, 2014, 6:41 p.m., Wolfgang Bauer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/117091/
> -----------------------------------------------------------
> 
> (Updated April 22, 2014, 6:41 p.m.)
> 
> 
> Review request for kde-workspace, Plasma 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.
> 
> This patch adds a signal handler for SIGUSR1 that switches the running greeter to immediateLock mode. The locker sends that signal to make sure the greeter shows the password input field when necessary.
> 
> 
> Diffs
> -----
> 
>   ksmserver/screenlocker/greeter/greeterapp.h 8b79188 
>   ksmserver/screenlocker/greeter/greeterapp.cpp c5e2f85 
>   ksmserver/screenlocker/greeter/main.cpp d898734 
>   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.
> 
> 
> Thanks,
> 
> Wolfgang Bauer
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140422/8586455e/attachment.html>