SUMMARY My touchscreen is a bit broken so there are times when it suddenly starts sending hundreds of click events to Plasma, so I fix this by bending the screen back to normal. The problem is, after receiving those click events, the mouse gets blocked in the "pinching" state with either the normal mouse icon or the pinching icon, as you can see in the video. The only workaround for this is doing keyboard shenanigans to log out gracefully and logging back in to restart Kwin. STEPS TO REPRODUCE 1. Trigger a lot of irregular click/hold events per second, no matter if it is just to the wallpaper, for at least 1 minute OBSERVED RESULT Mouse blocks itself in pinching mode and no matter what I hover, it doesn't go back to normal. EXPECTED RESULT Mouse should return to normal click mode after the chain of repeated click events. SOFTWARE/OS VERSIONS Windows: macOS: (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: Arch Linux + Linux zen 6.17.5 KDE Plasma Version: 6.5.1 KDE Frameworks Version: 6.19.0 Qt Version: 6.10.0 ADDITIONAL INFORMATION
Created attachment 186503 [details] Mouse blocked in pinching state (AV1 encoded warning)
Please run > sudo libinput debug-events reproduce the issue and then attach the output of that here.
The technician applied glue to the touchscreen so I can't reproduce it by myself so I will tell you what I saw in the logs and how exactly I could reproduce it. 1. As the touchscreen was hanging on one corner, the sensors would detect a really rapid, repeated and holding click on one point in the upper part of the screen, which I can't click fast enough and close enough to replicate. I know this thanks to the "Show touch points" effect in Plasma, which showed a fast flashing blue point at the top and all my actual clicks turned red, which seems to mean "second click". 2. After a while, a minute or something, even if I tried to unbend the screen, the laptop would start to ignore all of the touchscreen clicks, so the flashing blue dot disappears but also the red one and also programs and Plasma itself stopped responding to all kinds of clicks, left and right, but somehow gestures still worked, so I can zoom the screen in, move the mouse around, change virtual desktops. The only part where clicks remain working were on Overview. Everything else ignores clicks. 3. When I checked journalctl -b, it showed: Touchpad: kernel bug: Touch jump detected and discarded. So many times after that happened. The only way to get click working again is to log out and in. If I can reproduce the issue by hand, I'll be happy to include that info as well, but unfortunately it is too late. But I think that the main issue should still be fixed: Plasma should not start to ignore clicks if it receives a sudden rush of holding click events.
Created attachment 186632 [details] libinput logs
(In reply to Zamundaaa from comment #2) > Please run > > sudo libinput debug-events > reproduce the issue and then attach the output of that here. Good night (where I am). Finally I was able to properly reproduce the issue and gather some info. I can see that the GESTURE_HOLD_BEGIN and GESTURE_HOLD_END are properly registered both when this issue is happening and wnen it is working properly, but in this broken state Kwin nor the Qt programs respond to it. Weirdly, VLC responded to the clicks, but the browser doesn't. An additional quirk is that when I actually hold the click and want to move a window, for example, the hold is abruptly marked as ended in the logs and can't actually hold the window. I've just hit this bug again while writing this. It's so annoying. I have to restart Plasma once again.
I have another hypothesis for this. Turns out that my touchscreen might be detecting a phantom click from the screen, so when I try to click something else Plasma thinks "it is this long held click + the mouse click so the user might be pinching something" when I'm actually not. How did I figured it out, you'd ask? Because hard pressing at the bottom of the screen released that phantom click and actually let me click something else. But the Show clicks desktop effect doesn't actually paint the blue circle of that phantom click, so it is not actually visible in the screen. So maybe I'd reframe this issue to "avoid ignoring long held clicks to make it easier to detect phantom clicks" instead of addressing a real bug, hence why I'm changing the title now.