Created attachment 172255 [details] Native Wayland apps keep being marked as "unresponsive" SUMMARY Native Wayland clients keep being marked as "unresponsive" even after they recover. STEPS TO REPRODUCE 1. Launch any native Wayland application 2. Make it unresponsive 3. Let it become responsive once again OBSERVED RESULT It will be marked as unresponsive unless you minimize and bring it up again EXPECTED RESULT It should be no longer marked as "unresponsive" when it recovers SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.10.2-2-cachyos (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-7700K CPU @ 4.20GHz Memory: 15.6 ГиБ of RAM Graphics Processor: AMD Radeon RX 6700 XT ADDITIONAL INFORMATION This is only happening to Wayland native apps, X apps are working as intended. I'm using KWin from CachyOS repos with this patch applied https://invent.kde.org/plasma/kwin/-/merge_requests/5984 Before this patch some native clients would just crash. This behavior also could be reproduced on vanilla KWin 6.1.3 using Wayland-proxy
Can you describe how to make step 2 happen?
(In reply to Nate Graham from comment #1) > Can you describe how to make step 2 happen? It depends on applications. Easiest way to reproduce this is to run some game that locks its render thread during loading like CS2 or TF2. Don't know if it's still possible to run TF2 in Native Wayland, but for CS2 it's possible by changing "export SDL_VIDEO_DRIVER=wayland,x11" in cs2.sh
https://invent.kde.org/sitter/crashinator/-/commit/03f174adb7c7905f42df57ef221d062a2e7ac767 Glancing at the code that has to do with how we detect ANR on wayland. We send a ping to the surface when either the window gets focus or a window close is issued. You can actually see that very well in crashinator. - If you trigger a hang and do absolutely nothing (outside) the window will **not** turn unresponsive at all because kwin never sent a ping. - If you trigger a hang and change focus away and back, the window will turn unresponsive. - If you then do absolutely nothing again the window will stay unresponsive even after having recovered. - If you then again do a focus change the window will turn responsive again. `crashinator --platform xcb` meanwhile never detects the window as unresponsive unless you click close and then obviously it closes once it turns responsive again. We just outright have no means to detect unresponsive windows outside the close scenario. That said, the trouble appears to be that the the ever so late pong is eventually ignored by handlePongReceived because handlePingTimeout erased the serial and handlePongReceived was changed to only turn windows responsive if the serial is in m_pings.
Native applications are no longer marked as "unresponsive" when they become responsive again.