I have configured the top right screen corner to "Prevent Screen Locking". This seems to work, except when watching (streaming) Flash video. In that case, the screen saver comes up as usual, whether the cursor is in said hot corner or not. NB: my screen is NOT said to lock when the screensaver activates, maybe the issue I am reporting is related to a "de-separation" of the screen saving and screen locking functions? Is the hot corner action deactivated when no actual screen locking takes place? NB: I consider screen/terminal locking a feature of the screensaver and not the other way round. Please read my report with that knowledge in mind. Reproducible: Always Steps to Reproduce: 1. Configure a screensaver, deselect the option to lock the screen (ask for a password) to reproduce my configuration. Configure a hot corner that "Prevents Screen Locking" 2. Open a website with streaming (Flash) video content, and launch it fullscreen 3. put the mouse pointer in the hot corner you configured 4. Sit back to watch the video. Actual Results: The screensaver activates after the configured delay. Notice also how one sees a password dialog before the actual screensaver, DESPITE the fact that actual screen LOCKING has been deactivated. Expected Results: The screensaver ought not activate when the mouse pointer is in a hot corner that is supposed to "Prevent Screen Locking" regardless of what is on the screen. When the corresponding subsystem is configured NOT to lock the screen when the screensaver activates (i.e. NOT to ask for a pw. on screensaver exit), there ought not appear a dialog for entering a password; the screensaver ought to kick in immediately. I have not tried to activate screenlocking with a password to see if that influences the functioning of the "Prevent Screen Lock" hot corner action. Note that if this is not the case, i.e. the screen keeps locking during video playback, the issue gets a potential security aspect in that it might incite people to deactivate the lock-screen-when-screensaver-activates feature, or the screensaver all together. I also have not yet tested with local video playback in a dedicated application (which probably deactivates the screensaver itself, if written properly).
This issue still exists in 4.13 . It'd be nice if this bug were picked up and someone could react. It may seem a minor nuisance, but for people like my partner and I, who often watch documentaries for professional purposes, it gets to be a considerable PITA.
I am not sure it is fixable without adding inhibit support to Flash. The screen borders are problably not functional with fullscreen windows, because they might interfere with the application's input. Adding Thomas from KWin team, who better knows how the screen borders work.
As Christoph suggested, the core issue is that flash doesn't inhibit the screensaver. The active screen edge should work*, so i looked up the code: the feature is actually not implemented =P * There's a technical issue what I believe is the reason the implementation was "scheduled" and then forgotton. Screenlocker prevention should rather work fundamentally different from all other edges. Usually the cursor is pushed back for a while (you've to force it into the corner and also immediate re-activation needs to be prevented) and in case the action is triggered *once* For the Screenlocker prevention, the inhibit must immediately** be called when the edge is reached, the cursor NOT be pushed back and the locker uninhibited when the cursor is moved out of the corner** ** possibly with a short delay to hide brief toggles from dbus
(In reply to Thomas Lübking from comment #3) > * There's a technical issue what I believe is the reason the implementation > was "scheduled" and then forgotton. Screenlocker prevention should rather > work fundamentally different from all other edges. Indeed, it shouldn't work as a trigger but more like a dead-man's switch. As to Flash not inhibiting the screensaver ... if that's confirmed I maybe ought to open a report on Chrome/Pepper? Out of curiosity, does KDE/X11 provide an activity simulator as exists on OS X (which when called regularly prevents the screensaver from kicking in because it is as if the user is doing things) or is there another mechanism to inhibit screensaving transiently?
you could relatively easily judder the mouse using xdotool, but please don't ;-) KEKS=`qdbus org.freedesktop.ScreenSaver /ScreenSaver Inhibit "Me" "I am your god"` qdbus org.freedesktop.ScreenSaver /ScreenSaver UnInhibit $KEKS The screensaver dbus API also knows qdbus org.freedesktop.ScreenSaver /ScreenSaver SimulateUserActivity Not sure what that's supposed to be good for, but if you don't use an autostarting screenlocker, you'll find that flash neither prevents xdmps (screen turning off) xset -dpms turns dpms off and xset +dpms turns it on again.
(In reply to Thomas Lübking from comment #5) > you could relatively easily judder the mouse using xdotool, but please don't > ;-) Heh, no, I think I won't :) > Not sure what that's supposed to be good for, but if you don't use an I think it's the easiest way to prevent screensaving, locking or blanking without meddling with the settings of those features. There's always a risk they don't get reenabled if you use some call to disable them. If you simply make them believe the user is doing something (and watching a video is just that! ;) ) then there is no such risk; should Flash crash, the activity simulation disappears with the rest of it. > autostarting screenlocker, you'll find that flash neither prevents xdmps > (screen turning off) you mean Flash also doesn't prevent the screen from going into standby mode - if that's configured to happen? (In my case it isn't because that also kills audio-over-HDMI). > xset -dpms > turns dpms off and > xset +dpms > turns it on again. I know :)
*** Bug 315116 has been marked as a duplicate of this bug. ***
This never worked and was never fixed and since, as pointed out in comment #3, it doesn't even belong into the active screen corners (as it works entirely different) it will be removed from KWin. => https://git.reviewboard.kde.org/r/125701/ If there's still interest in such feature, the appropriate solution would be to have the screensaver/locker/powerdevil daemon check the mouse position whenever it feels like locking/powersaving the screen.
Git commit 5d37ccfce0907f4e8a393ae20c87d71fa65d9f9f by Martin Gräßlin. Committed on 21/10/2015 at 06:14. Pushed by graesslin into branch 'master'. Drop PreventScreenLocking electric border It was broken on so many ways, it's unbelievable: * action was read but did nothing * config was saved into a different file than read from REVIEW: 125701 M +0 -19 kcmkwin/kwinscreenedges/main.cpp M +0 -1 libkwineffects/kwinglobals.h M +0 -2 screenedge.cpp http://commits.kde.org/kwin/5d37ccfce0907f4e8a393ae20c87d71fa65d9f9f
too bad.. I still miss this feature currently, I disable all screenlocking/screensaver/energysaving just in case I'll be watching a video, which of course is too bad when I'm not watching a video ;) I wonder though: is everyone who watches a youtube video doing this..?
No. http://flavio.tordini.org/minitube
ps: ~/bin/minitube #!/bin/sh xset -dpms GOOGLE_API_KEY=<key> /usr/bin/minitube xset +dpms
*** Bug 339885 has been marked as a duplicate of this bug. ***