Bug 338962 - kscreensaver does not launch when a kwin effect is on
Summary: kscreensaver does not launch when a kwin effect is on
Status: RESOLVED DUPLICATE of bug 234153
Alias: None
Product: kscreensaver
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: NOR major
Target Milestone: ---
Assignee: kscreensaver bugs tracking
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-10 06:02 UTC by Moviuro
Modified: 2014-09-11 07:33 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Moviuro 2014-09-10 06:02:58 UTC
Today, big surprise: I opened my laptop and was greeted by my desktop grid instead of the usual kscreensaver asking for its password.
After a tiny little bit of testing/reproducing, it appears that the screensaver does not launch when a KWin effect is being displayed (tested with grid, present windows from {current desktop,all desktops})

Reproducible: Always

Steps to Reproduce:
1. Launch a KWin effect (e.g. Ctrl-F8 for desktop grid)
2. Go to sleep (close your laptop or anything that usually fires up kscreensaver)
3. Wake up

Actual Results:  
Kscreensaver has not been launched, you just have the effect still being displayed

Expected Results:  
Kscreensaver is being displayed (and the KWin effect has been discarded)

Version 4.14.0, not available in the drop-down menu.
Comment 1 Moviuro 2014-09-10 06:28:06 UTC
The real issue is actually not having to enter your password to re-login into your session. This could be a major security flaw, as I expect to see a password prompt as I open my laptop...
Comment 2 Christoph Feck 2014-09-10 12:33:58 UTC
Thomas, any idea why kwin effects could block the screen saver kicking in?
Comment 3 Thomas Lübking 2014-09-10 12:49:53 UTC
Input processing (redirection) -> mouse and kbd are necessarily grabbed.
Should affect at least present windows + desktop grid.

This cannot really fix on X11.
The only way around would be a protocol to have the screenlockers signal "i want the mouse! now!" and all clients reacting to it.

(Notice that the problem is not limited to kwin effects:
virtually all popups, some sort of autohiding panels, games and whatnot things grab the mouse/keyboard and then locking the screen isn't possible resp. pointless)

*** This bug has been marked as a duplicate of bug 234153 ***
Comment 4 Martin Flöser 2014-09-11 07:33:18 UTC
> This cannot really fix on X11.

to add to this: this bug will automatically be fixed by the switch to Wayland. 
On Wayland it is impossible for an application to grab keyboard/mouse and thus 
it's impossible to prevent the screen locker from kicking in.