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

Dario Freddi drf at kde.org
Mon Jan 14 22:06:47 UTC 2013



> On Jan. 14, 2013, 9:52 p.m., Dario Freddi wrote:
> > ksmserver/screenlocker/greeter/greeterapp.cpp, lines 272-275
> > <http://git.reviewboard.kde.org/r/108417/diff/1/?file=107301#file107301line272>
> >
> >     Just in case: should we check for the existence of the interface? I can picture a case where powerdevil is inactive. I guess in that case asyncCall would simply silently fail, but better safe than sorry.
> 
> Thomas Lübking wrote:
>     It'll silently fail whereas the query for the interface is a synchronous (blocking) call which needs either to be performed off-thread (pendingcallwatcher) or can timeout for (by default) 25 seconds in case something's wrong with dbus.
>     
>     It would only be worth it in order to use a fallback routine then (ie. calling DPMS directly, but than we would not have to perform the dbus trip anyway...)
> 
> Thomas Lübking wrote:
>     Addendum: of course that would be required in case we'd show a message and use a timered dpms off instead (we cannot lie to the user)

Definitely - OTOH, we also need the user to expect missing features when core components are deactivated, and in general powerdevil always needs to be unloaded purposefully. A different deal is if there's no DPMS support on the current screen, but I guess we would be trying to failsafe a bit too much at that point. We might get stuck in a discussion loop of screen locking vs. screen turning off in such cases, as a dialog wouldn't really make sense imho.


- Dario


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


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/20130114/3971b16d/attachment.html>


More information about the Plasma-devel mailing list