SUMMARY Nested Wayland window has issues painting updates, making it feel frozen/laggy. After keyboard input the changes are sometimes not visible until the mouse is moved. This is not exclusive to keyboard input e.g. the busy/loading animations when loading a website can freeze until the mouse is moved. STEPS TO REPRODUCE 1. Open a console and start a nested wayland server: $ kwin_wayland & 3. Set the new display: $ export WAYLAND_DISPLAY=/run/user/1000/wayland-1 4. Start a new console on the new display: $ konsole 5. Start continiously typing in the new console, hover the mouse over the nested display then move it outside of the nested display and stop moving the mouse. If the issue does not occur immediately play with the mouse and change window focus for at most a minute. OBSERVED RESULT New letters are not appearing on the nested wayland window. Moving the mouse seems to force a paint update and causes all newly typed letters to appear all at once. EXPECTED RESULT New letters appear on the nested wayland window immediately after typing without requiring any mouse movement. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux 6.14.7-arch2-1/ plasma-desktop 6.3.5-1 (Wayland) (fully up-to-date) KDE Plasma Version: 6.3.5 KDE Frameworks Version: 6.14.0 Qt Version: 6.9.0 ADDITIONAL INFORMATION * Host is running Wayland, nested compositor is also wayland. * When trying to capture the bug using spectacle the issue completely disappears. * amdgpu, tried using amdgpu.dcdebugmask=0x400 without improvement. * Issues never occur on the host, only on the nested compositor. * no errors on dmesg or journalctl. * tried lts and mainline kernel, same issue.
I updated today and I'm no longer able to reproduce the issue. If the issue comes back I might re-open the issue but I will close it for now. (on a up-to-date arch setup) kwin 6.4.0 KDE Frameworks: 6.15.0 Qt: Using 6.9.1 and built against 6.9.1 Arch Linux (Wayland) Build ABI: x86_64-little_endian-lp64 Kernel: linux 6.15.3-arch1-1
Taking liberty of reopening as I'm seeing this exact behaviour nesting under wlroots compositors (labwc, sway and cage tested). Weston unaffected. As well as the described triggering by Konsole (Yakuake too, unsurprisingly) - Firefox causes an even worse version where no input is required, it just constantly blocks redraws until the mouse is moved. I noticed that one other way of unblocking is to use certain kwin shortcuts such as Alt+Tab or Alt+F4. Operating System: Gentoo Linux KDE Plasma Version: 6.4.4 KDE Frameworks Version: 6.16.0 Qt Version: 6.9.1 Processors: 4 × Intel® Core™ i7-7600U CPU @ 2.80GHz Graphics Processor: Intel® HD Graphics 620
I don't know if it is helpful info, but I found that the symptoms are not seen when nesting a further layer deep: cage -> plasma-wayland -> weston -> konsole/yakuake/firefox
Please run the nested session with > WAYLAND_DEBUG=1 kwin_wayland -- env WAYLAND_DEBUG=0 konsole reproduce it not repainting, and then then attach the output of that here. I suspect that something's wonky with presentation time feedback.
Created attachment 184495 [details] console output log with debugging Cage did not play well with appending the above commandline directly to its own invocation so I placed it in a shellscript and issued the following: $ dbus-run-session cage -d -s -- ~/nesttest.sh &> cage-kwin.log Some not-super-precise context courtesy of a manual stopwatch: 00:10.36 - First observation of text typed in Konsole not appearing onscreen. Probably ~1s muscle delay, and an additional ~1-2s from the last mouse movement before typing 00:13.77 - Subsequent mouse movement that triggered redraw
🐛🧹 ⚠️ 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!
Sorry, I missed changing the status when I added the log.
Hmm, I have an idea: What happens if you leave something else running on the screen in the host compositor that triggers constant repaints, like eglgears_wayland?
I didn't get the free time I was hoping at the weekend to address this properly, but I got as far as establishing that: 1) eglgears_wayland seems unknown to Gentoo Portage. In mesa-progs package I do have es2gears_wayland which hopefully meets the same objective. 2) Requested action requires me to restore one of the other wlroots compositors previously tested, as cage can only run a single application. I will try with labwc. I should definitely have time to look at this later this week.
Created attachment 186039 [details] console debug output, labwc - kwin_wayland - konsole Attached output from running the same test command as above, this time inside a SDDM-launched labwc session. Synopsis: 1. Ran test command from Foot terminal app with its window set to "Always on top" in labwc. kwin_wayland window opens ovelapping foot window. 2. Typed "exit<ENTER>". No redraw of kwin_wayland window. 3. Focused foot window with mouse. kwin_wayland redraws, showing konsole exited. 4. Closed kwin_wayland window (traversing its area with mouse to do so). No stopwatch this time but can do that if it helps. Regarding es2gears_wayland: I did experiment with this first, but it did not by itself trigger redraws of the kwin_wayland window, even when positioned on top of that window and set Always On Top by the WM. The same is true with foot, when I ran the test command without redirection (so there was constant redrawing in foot as the debug output spewed). On the other hand, anything redrawing the area over the kwin_wayland window at the WM level, e.g. hovering the 'Minimise' button on the overlapping window, did trigger a redraw. Notably, unlike in the previous testing with cage, here there were no redraws at all, from the very outset, until a triggering action was taken. Mouse movement by itself had no effect either way. (Mind you a multi-window compositor in place of cage running kwin_wayland fullscreen is presumably bound to have differences like this.)