| Summary: | Nested wayland compositor stops redrawing until the mouse is moved | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | ungoogled1 |
| Component: | platform-wayland-nested | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | kde.bugs, xaver.hugl |
| Priority: | NOR | ||
| Version First Reported In: | 6.3.5 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: |
console output log with debugging
console debug output, labwc - kwin_wayland - konsole |
||
|
Description
ungoogled1
2025-05-24 23:45:51 UTC
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.)
|