I mainly use the two-finger scroll gesture to scroll in applicatios. Since I began using the Wayland session of KDE in Plasma 5.15.1 / Frameworks 5.55, I have been triggering a bug that applications running under XWayland sometimes behave as if I'm scrolling downward. STEPS TO REPRODUCE This problem happens occasionally, and I'm sorry that I haven't discovered a reliable way to reproduce it. 1. Open an application that runs under XWayland (such as chromium or firefox) 2. Open a long document 3. Use touchpad to scroll downward. I'm not sure if a long or jerk scroll has a higher chance to trigger it. OBSERVED RESULT If this bug happens, you will see the page scrolling down rapidly even though fingers are off the touchpad. Moving the cursor to the tab bar of chromium will cause the tabs to switch rapidly. The bottom of a more-than-thousand-page PDF document can be reached instantly in firefox. Performing a two-finger upward scroll will work (cause the page to move upward) for a moment. But the page will continue to scroll downward after fingers stop moving upward. To stop the spurious scrolling, I can type something into the application or send a Ctrl-T shortcut to chromium. However, once this bug happens, it will be more often triggered when I scroll downward in applications, until I reboot my laptop. Scrolling upward can also trigger the applications to spuriously scroll upward, nevertheless I mainly scroll downward. EXPECTED RESULT Applications scroll normally. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.2.9-arch1-1-ARCH KDE Plasma Version: 5.16.4 KDE Frameworks Version: 5.60.0 Qt Version: 5.13.0 libinput version: 1.14.0 ADDITIONAL INFORMATION I'm able to perform tap-to-click in XWayland applications along with the spurious scrolling. This bug doesn't affect native wayland applications including dolphin, konqueror, kate or gedit. That is, moving cursor into these applications won't cause them to scroll, while moving it into another nearby xwayland window will cause it to scroll crazily. However, if I force them into using XWayland by setting GDK_BACKEND=x11 or QT_QPA_PLATFORM=xcb, they will scroll downward indefinitely as long as the cursor is in their windows. Firefox runs with MOZ_USE_XINPUT2=1. Chromium doesn't use XInput2 because of https://crbug.com/712737 I have tried applying the kwin patch for bug 404152 to kwin 5.16.4, but I still triggered this bug moments before. A similar report can be found on the Internet: https://forum.manjaro.org/t/xwayland-apps-scrolling-on-their-own-in-a-kwin-wayland-session/58096
Given that you've applied patch for bug 404152 and native wayland clients are not affected, it seems like that's an xwayland issue. Have you filed similar bug report against xwayland? or does this issue occur only when running kwin/wayland?
Actually kwin is the only wayland compositor I've used so far, so I don't know if it happens in other compositors. Shall I switch to another DE (like GNOME?) or is it possible to plug another compositor into KDE? This bug usually happens after using the laptop for a long period (laptop started in the morning, windows start to malfunctioning in late afternoon or at night)
Today I observed that spurious "Home" keys were sent to XWayland applications after a period of usage. So the scope of this bug might not be confined to touch events? Linux/KDE Plasma: 5.3.0-arch1-1-ARCH KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.13.1 libinput version: 1.14.1
Still happens after upgrading to new version of KDE. However the frequency seems to be lower. Linux/KDE Plasma: 5.3.7-arch1-2-ARCH KDE Plasma Version: 5.17.2 KDE Frameworks Version: 5.63.0 Qt Version: 5.13.1 libinput version: 1.14.3
Also, there are lots of messages in dmesg like: psmouse serio2: Touchpad at isa0060/serio2/input0 lost sync at byte 6 psmouse serio2: Touchpad at isa0060/serio2/input0 - driver resynced. Not all of such messages will lead to this bug, but this bug seems to happen after some of these messages sometimes. I have identified a dirty fix for this issue: Close the lid to suspend the laptop. After resuming, this problem would be gone for the moment. However it might still re-appear some time later.
Created attachment 124863 [details] Events logged with xinput test-xi2 --root I discover that to trigger this issue, the focus has to be changed into the XWayland window - that is, suppose Chromium and Konsole are placed side-by-side and the current focus is in the latter's window. If I move the pointer onto Chromium, nothing happens and I can scroll the content inside using gestures without hassle. However, if I click the Chromium window to switch the focus to it, this issue will be exhibited. The attachment is a sample log obtained with xinput test-xi2 --root . It seems to be pretty messy, and I have to admit that I don't have much knowledge about the input stack. Anyway I will try to describe what I have done. At Line 8, I moved the cursor from a Wayland window into Chromium's XWayland window. Then the cursor continued moving in XWayland until maybe Line 266, when I began to perform two-finger scroll in it. That should end at Line 935, when I began moving the cursor back to the adjacent Wayland window. It should finally reach the border at Line 1335. After a while, I began the next part of the experiment and the cursor entered XWayland maybe at Line 1345? It moved for a short time before I did a tap-to-click gesture at Line 1555. Then a storm of spurious events happens, where all seem identical to the one from Line 1567 to Line 1577. The effect of this event should cause Chromium to scroll upward infinitely this time. I tried to perform a two-finger downward scroll, but it would be greeted with this spurious upward scroll and cancels the effect of previous operation. Or in a separate trial not attached here, I tried to drag the scrollbar to scroll downward by using "tap-to-hold" gesture and drag it in that direction. But as soon as I release my finger, it just scrolls upwards again. Then at Line 3955, I pressed the "T" key on my keyboard. After that, the problem is gone and I can scroll in that window as usual. It's worth mentioning that keys for alphabets or numbers do this trick, but clicking "Ctrl" won't work and Chromium keep scrolling. Linux/KDE Plasma: 5.4.6-arch3-1 KDE Plasma Version: 5.17.4 KDE Frameworks Version: 5.65.0 Qt Version: 5.14.0 libinput version: 1.14.3
Haven't met this issue since I switched to GNOME 3 two weeks ago, so I suspect this is a KDE-specific bug. The wayland session of GNOME is more stable than that of KDE, so I will probably stick to GNOME for the time being. However I still miss many features of KDE, and I will be willing to help with this issue if someone decides to work on it or can provide some instructions to collect debug information.
Hitting this bug occasionally as well. Right now on Plasma 5.18.5 and KF5 5.70.
Created attachment 132295 [details] xev log it seem it is actually the up key and pressing it once makes it stop.. but as you see from the xev logs it does get spammed, I just don't know _what_ spams it, but I expect it's kwin as nothing else could it be.
actually.. it seems to be the "home" button and a couple of keys make it stop. Tab seems to be another one. Also, can we please fix this bug as this essentially makes Plasma unusable...
Could you please confirm that it's still a problem?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
This is still happening for me (literally as I write this). Once it happens for the first time in a session, I can trigger it with 100% reliability by switching from an xwayland window to a native wayland window and back. Here's a demo showing xev getting events but evtest showing nothing: https://www.youtube.com/watch?v=gTvpvt-suxk If there's any more info you need please let me know Operating System: Arch Linux KDE Plasma Version: 5.24.1 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 Graphics Platform: Wayland Graphics Processor: Mesa Intel® HD Graphics 630
I am unable to reproduce. Can you confirm if this is still an issue?
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.