Bug 399572

Summary: Compositing interruption during "present windows" effect disables keyboard / mouse input
Product: [Plasma] kwin Reporter: Mahendra Tallur <mahen>
Component: compositingAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: nate
Priority: NOR Flags: vlad.zahorodnii: Wayland-
vlad.zahorodnii: X11+
vlad.zahorodnii: ReviewRequest+
Version: 5.15.1   
Target Milestone: ---   
Platform: Neon   
OS: Linux   
URL: https://phabricator.kde.org/D19178
Latest Commit: https://commits.kde.org/kwin/38e22ce6d18ca3f71cc1b3213ce4fc7de9cc8ef4 Version Fixed In: 5.15.3

Description Mahendra Tallur 2018-10-09 18:45:25 UTC 
SUMMARY

If you start an app that explicitly tells kwin to disable compositing, and if, meanwhile, you trigger the "present windows" effect, and if the aforementioned app actually disables compositing while the effect is still active, the subsequent keyboard and/or mouse inputs have no effect.
(also, some windows decoration may flicker / intermittently disappear)

STEPS TO REPRODUCE
1. Create a kwin rule to permanently disable compositing when a given app is started. In my case, I did this for the Steam client. This way I'm sure all games will have compositing turned off to improve performance.
2. Open several windows
3. Start the aforementioned application (preferably, an app that takes a few second to actually display its window)
4. Quickly trigger the "present windows" effect (hot corner or CTRL-F9)

OBSERVED RESULT

When the application is displayed, compositing is disabled, and the "present windows effect" is disabled.

Then, one can notice that keyboard input doesn't work anymore. Only the "windows key" works here and triggers the K Menu. Sometimes it also affects the mouse which can move but whose clicks have no effect anymore (except in the log-out menu !)

Some windows decorations are also corrupted.

EXPECTED RESULT

The "present windows" effect should be interrupted when the app is displayed and compositing is disabled but the keyboard & mouse should continue to work...

SOFTWARE VERSIONS
(available in About System)
KDE Plasma Version: 5.14.0
KDE Frameworks Version: 5.50.0
Qt Version: 5.11.1

ADDITIONAL INFORMATION

KDE Neon 18.04
Comment 1 Vlad Zahorodnii 2019-02-20 10:57:23 UTC 
So, I spent some time investigating why the hell this bug happens. Apparently, doUngrabKeyboard has to be re-implemented by a Platform sub-class. The only problem is that it's not a good idea to call a virtual method from the destructor of a base class.
Comment 2 Vlad Zahorodnii 2019-03-11 07:25:26 UTC 
Git commit 38e22ce6d18ca3f71cc1b3213ce4fc7de9cc8ef4 by Vlad Zagorodniy.
Committed on 11/03/2019 at 07:23.
Pushed by vladz into branch 'Plasma/5.15'.

[platforms/x11] Properly unload effects on X11

Summary:
When Compositor finishes compositing, it destroys EffectsHandlerImpl,
which in its turn tries to unload all effects. But there is a problem...

EffectsHandlerImpl has platform-specific hooks to ungrab keyboard and
also stop mouse interception. Given that any call made to a virtual function
in the destructor of a base class(EffectsHandlerImpl) won't go to a derived
class(EffectsHandlerImplX11), keyboard won't be ungrabbed even if effect
that grabbed it is already gone.

Reviewers: #kwin, davidedmundson

Reviewed By: #kwin, davidedmundson

Subscribers: kwin

Tags: #kwin

Differential Revision: https://phabricator.kde.org/D19178

M  +11   -1    plugins/platforms/x11/standalone/effects_x11.cpp
M  +1    -1    plugins/platforms/x11/standalone/effects_x11.h

https://commits.kde.org/kwin/38e22ce6d18ca3f71cc1b3213ce4fc7de9cc8ef4
Comment 3 Mahendra Tallur 2019-03-12 19:33:50 UTC 
Thank you, again, so much for the fix, Vlad !
Comment 4 Vlad Zahorodnii 2019-03-12 19:38:08 UTC 
np :-)