> On April 24, 2014, 10:01 p.m., Thomas Lübking wrote: > > ksmserver/screenlocker/greeter/main.cpp, line 94 > > <https://git.reviewboard.kde.org/r/117091/diff/7/?file=268053#file268053line94> > > > > was there a problem with SA_RESTART? > > > > --- > > > > KDE Workspaces 4.11.9 tagging: > > Fr 25. Apr 01:59:00 CEST 2014 > > > > Would you be ok to give Martin until > > Fr 25. Apr 00:01:00 CEST 2014 > > and then push it (on my responsibility)? > > Wolfgang Bauer wrote: > Haven't tried SA_RESTART. I will do so now. > > It's ok for me to push at Fr 25. Apr 00:01:00 CEST 2014, so I will at > least wait until then. > > Wolfgang Bauer wrote: > Changed it to SA_RESTART now, let the system automatically > suspend/hibernate a few times, and also started kscreenlocker_greet manually > and sent it SIGUSR1 a few times. > This worked as expected too, I haven't experienced any problems. > So I suppose SA_RESTART is ok as well. > > Thomas Lübking wrote: > SA_RESTART seems the BSD default and used by "legacy" signal() > > Thus I was actually rather concerned that w/o SA_RESTART some EINTR could > lead into an abort - though even in that case we'd just end up with a > restarted greeter. > Since you've been running it w/o so far, I'd sugest to push that version > and keep testing SA_RESTART afterwards to change the behavior in master and > eventual 4.11.10 to use SA_RESTART then. > Ie. keep "0" for now as that's the better tested variant.
OK. I'm more comfortable with that as well, anyway. - Wolfgang ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117091/#review56415 ----------------------------------------------------------- On April 24, 2014, 10:52 a.m., Wolfgang Bauer wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/117091/ > ----------------------------------------------------------- > > (Updated April 24, 2014, 10:52 a.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 > >
