I use Fn+F1 (aka KEY_MUTE), Fn+F2 (aka KEY_VOLUMEDOWN) and Fn+F3 (aka KEY_VOLUMEUP) to control my volume levels on Plasma. When I press Fn+F1, and then release F1 while keeping Fn pressed, the volume state keeps muting/unmuting although no keys are being pressed during that time (just like the key is stuck). It only stops when i release the Fn key. Same applies for Fn+F2 and Fn+F3 keys: the volume level keeps going down/up after the release of F2/F3 (but with Fn still pressed). I tried running "libinput-debug-events", it reports correctly about key press/release events. Reproducible: Always I use KWin 5.7.95, with KF 5.26.0 and Qt 5.7.0.
Also, it might be related. If I have e.g. lots of chromium windows with single tab (so closing this tab will close the window) and then press Ctrl+W, it closes several (usually 2 to 3) windows instantly, just like Ctrl+W is stuck. Although it doesn't happen if I have just multiple tabs opened in a single chromium window: single tab is being closed and that's it.
The chromium issue is an Xwayland issue which will be fixed with Xwayland 1.19. Can you please start the KWin debug console (Krunner, enter KWin) and switch to the input tab and see there which events are being processed?
(In reply to Martin Gräßlin from comment #2) > The chromium issue is an Xwayland issue which will be fixed with Xwayland > 1.19. > > Can you please start the KWin debug console (Krunner, enter KWin) and switch > to the input tab and see there which events are being processed? Okay, there are a lot of things going on there. 1) When I just press "Fn" key, there goes the "Key Press" event from "AT Translated Set 2 keyboard (event 0)", scan code 143 (apparently, this is KEY_WAKEUP), Xkb symbol 269025067. 2) While holding the Fn key, I press F2 key. There goes "Key Press" event from the same keyboard, scan code 114 (KEY_VOLUMEDOWN), Repeat: 0, Xkb symbol: 269025041. 3) I keep the "F2" key pressed; there appears lots of Key press events, as expected. 4) When I release the "F2" key while keeping the "Fn" key pressed, there goes "Key release" event, same as in 2) And now the interesting part: 5) If I keep holding the "Fn" key, there goes lots of "Key press" events, Input Device: Unknown, Repeat: 1, Scan code: 143, Xkb symbol: 269025041. Those events are apparently misinterpreted as Volume down/up events, although the key is released
By the way, it seems like the debug console doesn't close properly if I use the cross on window decorations to close it instead of "Quit debug console". I've made several (around 10 or something) reruns in order to get what's happening here; and each time I've closed the console using close button on the decoration. After that there was massive slowdown of the input: KWin started using 100% CPU when I moved the mouse, and the input field reacted on the keyboard buttons pressed with the visible lag (up to a second). After starting a fresh wayland session, everything is back to normal.
I think I understand the problem
The FN key starts to repeat (which it shouldn't in my opinion, but that doesn't matter here) and as repeat code we use the last symbol - which was from the volume key. But we need to repeat with the symbol the key triggered.
Problem from comment #4 reported as bug #369858
Further investigation from testing repeat behavior of X11, Qt/Wayland shows that key repeat gets canceled as soon as another key is pressed. Which means the repeat of the FN key should stop as soon as the F2 key is pressed.
Git commit 48db671684c6257161b4a438fe3f0a7dda7ede31 by Martin Gräßlin. Committed on 04/10/2016 at 14:02. Pushed by graesslin into branch 'Plasma/5.8'. [autotests/integration] Add test case for repeating shortcuts This adds a new test case for global shortcuts which simulates triggering a shortcut through key repeat. The test verifies a problem that the the shortcut continues to be triggered after releasing the key if another key is still pressed (and triggers repeats). M +41 -0 autotests/integration/globalshortcuts_test.cpp http://commits.kde.org/kwin/48db671684c6257161b4a438fe3f0a7dda7ede31
Addressed with https://phabricator.kde.org/D2941
Git commit 3bc608939444f88dd855130982ce176d393d3ab5 by Martin Gräßlin. Committed on 06/10/2016 at 11:26. Pushed by graesslin into branch 'Plasma/5.8'. Only repeat one key Summary: So far KWin tried to repeat all pressed keys which should repeat. But this is not how X11 and e.g. QtWayland handle it. There only one key - the last one which got pressed - repeats. And this makes sense as the key is used to generate a keysym and that one KWin caches. Thus the logic so far resulted in incorrect keysyms to be generated during the repeat. E.g. pressing a, pressing b, releasing b would repeat b instead of the hold a as b was the last generated keysym. This change addresses this problem and let's only one key repeat at a time. When the currently repeating key gets released the repeat timer is stopped and other hold keys won't repeat any more. This also matches the behavior of X11 and QtWayland. FIXED-IN: 5.8.1 Reviewers: #kwin, #plasma_on_wayland Subscribers: plasma-devel, kwin Tags: #plasma_on_wayland, #kwin Differential Revision: https://phabricator.kde.org/D2941 M +0 -1 autotests/integration/globalshortcuts_test.cpp M +19 -23 keyboard_input.cpp M +5 -1 keyboard_input.h http://commits.kde.org/kwin/3bc608939444f88dd855130982ce176d393d3ab5