When playing Team Fortress 2, Counter Strike Global Offensive or Euro Truck Simulator 2, escape key is not detected. Following are the steps to reproduce: 1. Launch game. 2. Enter a game session (or go anywhere escape input can be detected). 3. Scenario 1: escape key won't work. Scenario 2: escape key works, but stops working when after switching to another application and switching back to game window.
Which Xwayland version are you using?
I am using Xwayland 1.19.3
How are you pressing the escape key? A long press or a short press and release?
A short press and release.
(In reply to Rajdeep Nanua from comment #4) > A short press and release. meh, a long press I would have understood what goes on.
I just tried it on KDE Neon with self compiled Xorg Server / XWayland from Git and Neverball, that shows a similar behaviour in the following way: * Start Neverball in XWayland mode: In main menu with mouse interaction everything fine. Esc works. Start a level and message "Pointer motion confined..." in the left up corner. Pointer motion is somewhat miscalculated though. Neither short or long press Esc does something. When the level finishes the message appears again shortly and the mouse cursor is shown again (end menu screen). I can't move the mouse cursor though. Long press Esc releases the mouse cursor and afterwards short Esc works again. * Start Neverball in Wayland native mode (export SDL_VIDEODRIVER=wayland): No message appears. Esc and everything else works.
Created attachment 104956 [details] Workaround to get escape key working in games I narrowed down the problem to a specific problematic code in input.cpp. With escape-workaround.patch, escape key works. Hope that helps isolate the issue.
That this code segment is responsible for it was already obvious to me :-)
The bigger question is on the why it happens. The code should let short presses through and that is not happening.
After re-reading the code I think I understand the problem. We send a keyboard leave event to Xwayland whenever escape gets pressed. We need to delay it till we trigger.
Proposed patch: https://phabricator.kde.org/D5488
Unfortunately, that patch did not fix the issue for me.
I am also facing the issue on KWin 5.9.5 and XWayland 1.19.3
Moving m_timer->start to after passToWayland has been called seems to fix the problem while allowing to break out of pointer confinement by holding esc for 3 seconds. See p1.patch.
Created attachment 105427 [details] p1.patch
I must say that I don't understand (yet) why moving the timer changes anything
So I analyzed the patch and it is quite similar to my change. The result is partially the same. The moving of the timer has the same effect as the removal of "input()->keyboard()->update();" in my change. The main difference is that passToWaylandServer happens in your change but not in my change. Although I assumed that a later filter would do that. This might explain why my change doesn't work. What your change doesn't support right now is the hiding of escape from the window on a long press which cancels the pointer grab. I guess we need the best of both approaches ;-)
I updated the phab request. Given the autotest the escape key should be passed to the application now.
That works! Thanks a bunch, Martin.
Will be fixed with the patch going into repo
Git commit 229be65e4002987e2de0113ef9b7140492d2d681 by Martin Flöser, on behalf of Martin Gräßlin. Committed on 12/05/2017 at 05:06. Pushed by graesslin into branch 'Plasma/5.9'. Improve the escape key handling for breaking constrained pointers Summary: So far KWin started to filter out the escape key as soon as it gets pressed. This was done by unsetting keyboard focus. The idea was to reset keyboard focus when it is only a short press and that then the keyboard state is correct for the application. But in practice this does not work. The only application currently supporting pointer constraints (Xwayland) does not do anything on a key which is pressed when gaining keyboard focus. The result is escape not working in pointer constrained Xwayland windows. This change addresses this problem by changing the interaction to only unset keyboard focus when our break constraints condition is met. This should also result in the application not handling the key release, but it means it gets the key press. Unfortunately I don't have a good way to test. Test Plan: None Reviewers: #kwin, #plasma Subscribers: plasma-devel, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D5488 M +3 -2 autotests/integration/pointer_constraints_test.cpp M +5 -3 input.cpp M +1 -1 keyboard_input.cpp https://commits.kde.org/kwin/229be65e4002987e2de0113ef9b7140492d2d681
When testing this out I encountered one time a session breaking failure: ASSERT: "m_spy.isNull()" in file /home/roman/Entwicklung/kde/source/kde/workspace/kwin/onscreennotification.cpp, line 204 I assume it's about the notification in upper left corner that the pointer constraining is active, but could be unrelated to the change here. Never seen it before though.
(In reply to Roman Gilg from comment #22) > When testing this out I encountered one time a session breaking failure: > ASSERT: "m_spy.isNull()" in file > /home/roman/Entwicklung/kde/source/kde/workspace/kwin/onscreennotification. > cpp, line 204 > > I assume it's about the notification in upper left corner that the pointer > constraining is active, but could be unrelated to the change here. Never > seen it before though. It's a bug, but unrelated. Unfortunately it's one of those things we cannot test in the integration tests as it requires QtQuick and that cannot be run on the CI system as we don't have OpenGL there.