Review Request 108417: screenlocker make [escape] "conditionally" turn off the screen

[Thomas Lübking]

> On Jan. 16, 2013, 4:07 p.m., Oliver Henshaw wrote:
> > I'm not sure about this. I do think that control of when to trigger e.g. dpms and dimming should shift from powerdevil to screenlocker (leaving the mechanism in powerdevil) but this seems a strange place to start.
> > 
> > If this is a companion to https://git.reviewboard.kde.org/r/108375/ (but for the simple locker) then what about just dismissing the unlock dialog on Escape? This is what the old screensaver did if I read correctly. In fact, is that an approach that works for all varieties of locker?

The unlock dialog cannot be dismissed, it's what protects the screen against content exposure - it /is/ the screenlocker by the new architecture and afaiu.
The "screensaver" is just fancy stuff on top of it for whoever wants that, but it's not relevant in the locking mechanism.

I don't think dimming belongs into the locker at all (why?) and Aaron preferred to keep the ability to dpms in one place and not link Xdpms from the locker/greeter.

As pointed out, i believe that in the long run dpms (and pot. dimming if it's not) should be abstracted in solid, but for now it has to be done on the workspace layer and (only) powerdevil already has it.

I frankly don't know what the "simple locker" configures as screensaver (no screensaver, no screensaver kcm, not gonna happen ;-) but if it disables m_showScreenSaver in the locker app, then yes - this is gonna just turn off your screen when you press escape from the locker instead of showing some fancy animation.

Notice that i'm a foreigner in this context - i've no idea who's in charge of screenlocking / saving and just hooked on when there was this stir on k-c-d.

I'll hold the push back for the next 3 hours (20:30 CET) to resolve pending questions.


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108417/#review25663
-----------------------------------------------------------


On Jan. 14, 2013, 9:12 p.m., Thomas Lübking wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108417/
> -----------------------------------------------------------
> 
> (Updated Jan. 14, 2013, 9:12 p.m.)
> 
> 
> Review request for Plasma and Dario Freddi.
> 
> 
> Description
> -------
> 
> Requires https://git.reviewboard.kde.org/r/108416/
> This calls powerdevil to turn off the display when the user presses escape, or rather every second time s/he does so.
> 
> Afaics the powerdevil infrastructure does not allow us to query this value from the DPMS Action (different from the stuff that is implemented in backend) so to check whether the screen is currently active (and i actually believe, this is gonna fail as well, because the state is likely reset on wakeup before we receive the event, esp. for a dbus call) we'd either have to link DPMS in the locker ... or invoke a cheap trick, ie. "s/conditionally/every other time/g"
> 
> Another way i could think off would be to add a message on the QML (like the caps lock) that the screen is gonna be turned off in 10 seconds and skip that when the user starts to interact (any mouse or key events)
> That's probably the more fair way to say that we cannot otherwise reasonably handle screenstate toggling - i just worry nobody actually reads such messages *shrug*
> 
> 
> Diffs
> -----
> 
>   ksmserver/screenlocker/greeter/greeterapp.h f332bfc 
>   ksmserver/screenlocker/greeter/greeterapp.cpp c8e95bd 
> 
> Diff: http://git.reviewboard.kde.org/r/108417/diff/
> 
> 
> Testing
> -------
> 
> Yes, reliably toggles the screen even after press-holding the escape key (then wait for the actual screen state and then controlled toggling it)
> 
> 
> Thanks,
> 
> Thomas Lübking
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130116/3af53af0/attachment.html>