Review Request 119814: [ksld] ScreenLocker inhibits sleep on logind

Martin Gräßlin mgraesslin at kde.org
Thu Aug 21 15:19:19 UTC 2014



> On Aug. 21, 2014, 3:57 p.m., David Edmundson wrote:
> > ksmserver/screenlocker/ksldapp.cpp, line 213
> > <https://git.reviewboard.kde.org/r/119814/diff/1/?file=305920#file305920line213>
> >
> >     this is adding monitoring logind telling us we're going to sleep, but it worked before, so this must mean now we're going to be trying to lock from two places?

> but it worked before

That is true and not true at the same time. Ksld never noticed whether the system goes to sleep. Try it yourself:
systemctl suspend

and it doesn't lock.

But if one suspend through powerdevil (which is broken on my system and the reason for this change) it calls the DBus interface of ksld to lock. But this brings the disadvantage that it's not properly controlled - powerdevil can never know when the lock is in place and as far as I read the code it just starts it. That's why my commit message states that it needs adjustements in powerdevil to prefer suspending through logind if available.


> On Aug. 21, 2014, 3:57 p.m., David Edmundson wrote:
> > ksmserver/screenlocker/ksldapp.cpp, line 219
> > <https://git.reviewboard.kde.org/r/119814/diff/1/?file=305920#file305920line219>
> >
> >     this seems rather major.

see my initial comment: I'm requesting feedack on where to put the config option.


- Martin


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


On Aug. 17, 2014, 5:10 p.m., Martin Gräßlin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119814/
> -----------------------------------------------------------
> 
> (Updated Aug. 17, 2014, 5:10 p.m.)
> 
> 
> Review request for Plasma and Àlex Fiestas.
> 
> 
> Repository: plasma-workspace
> 
> 
> Description
> -------
> 
> [ksld] ScreenLocker inhibits sleep on logind
> 
> When the system is going to sleep we want to ensure that the screen gets
> locked before the system goes to sleep. Logind provides the inhibitor
> locks which can be used for this.
> 
> If logind is available ksld gains an inhibitor lock for sleep when the
> screen is unlocked. As soon as the screen gets locked the inhibitor lock
> is released. In addition it connects to the prepareForSleep signal by
> logind and locks the screen.
> 
> The solution needs to be extended to have a config option whether the
> screen should be locked on sleep. Currently this is provided by
> powerdevil. Also the solution can only work properly if power devil uses
> logind's sleep dbus interface.
> 
> [ksld] Don't block till the greeter is started
> 
> We only want to ensure that the greeter gets started. There is no
> need to block for that. Instead we can connect to the error signal
> and unlock in case the greeter failed to start.
> 
> 
> -----
> @Alex: what do you think is the best solution for handling the "lock screen on resume" config option? My idea would be to move it to screen locker and expose the value through DBus, so that powerdevil can still read it.
> 
> 
> Diffs
> -----
> 
>   ksmserver/screenlocker/logind.h a335ddc2f6f55b071f824f9da94652a4dd70c483 
>   ksmserver/screenlocker/logind.cpp dcfc7f321b3cf29ef68aac8006aa37f5e4e00956 
>   ksmserver/screenlocker/CMakeLists.txt 5378a10df2be70cee95b5612c23046eae639f610 
>   ksmserver/screenlocker/autotests/CMakeLists.txt 4bff1c6b1d8fc360197c422f8d036dff3eae5efe 
>   ksmserver/screenlocker/ksldapp.h 095424c9845c134aa156917aeb6c8ddf31e8d25a 
>   ksmserver/screenlocker/ksldapp.cpp 04c7db366722f61dd87407d557ccf7d04ce83bcc 
> 
> Diff: https://git.reviewboard.kde.org/r/119814/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20140821/6f7f7983/attachment.html>


More information about the Plasma-devel mailing list