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