| Summary: | Tearing not working on Wayland | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Syntist <syed.talha.khalid> |
| Component: | compositing | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | oleg, xaver.hugl |
| Priority: | NOR | Keywords: | usability, wayland-only |
| Version First Reported In: | 6.3.2 | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Syntist
2025-02-16 07:34:35 UTC
Can you please post the output of drm_info? Also do you atomic modesetting or legacy modesetting? or whatever is default? If you run > WAYLAND_DEBUG=1 vkcube --wsi wayland --present_mode 0 2>&1 | grep set_presentation_hint does that output something like > [3298581.344] {mesa vk display queue} -> wp_tearing_control_v1#22.set_presentation_hint(1) > [3298587.277] {mesa vk display queue} -> wp_tearing_control_v1#32.set_presentation_hint(1) ? If you set a window rule to force tearing for a specific window, do you see tearing then? When i run vkcube, i did get this, but i didn't notice any tearing and the mode didn't change either. [3839653.928] -> wp_tearing_control_v1#22.set_presentation_hint(1) [3840830.536] -> wp_tearing_control_v1#22.set_presentation_hint(1) This is the drm_info output https://paste.cachyos.org/p/0f02857 Also can it be cause I am using modified edid, that's load in boot time. Also am using default which is atomic modesetting I also tried with window rules, I can't seem to get it too tear. Tearing is prominent on windows with same game, like cs2 etc. Issue persistent in kde 6.3.2 Okay, then please follow https://invent.kde.org/plasma/kwin/-/wikis/Debugging/Debugging-DRM-issues to record a drm debug log of KWin attempting to use tearing. If it does attempt it at least, we should see in that log why it doesn't work. (In reply to Zamundaaa from comment #6) > Okay, then please follow > https://invent.kde.org/plasma/kwin/-/wikis/Debugging/Debugging-DRM-issues to > record a drm debug log of KWin attempting to use tearing. If it does attempt > it at least, we should see in that log why it doesn't work. Hey, I did see Fetch create, related outputs but I can't much of it as I don't have much understanding of DRM, But here is the log maybe it can help https://paste.cachyos.org/p/ecc01e5 Good, some progress: > [drm:intel_atomic_check [i915]] [PLANE:77:cursor A] async flip not supported KWin intentionally falls back to a software cursor when trying to do tearing, so that's nonsense. With the knowledge that this must be driver specific rather than something on your system, I also tested this on an Intel laptop and got the same result. I also made sure that the cursor plane is actually disabled while these messages are printed, so this is without a doubt a kernel bug. You can follow this further at https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13834 (In reply to Zamundaaa from comment #8) > Good, some progress: > > [drm:intel_atomic_check [i915]] [PLANE:77:cursor A] async flip not supported > > KWin intentionally falls back to a software cursor when trying to do > tearing, so that's nonsense. With the knowledge that this must be driver > specific rather than something on your system, I also tested this on an > Intel laptop and got the same result. I also made sure that the cursor plane > is actually disabled while these messages are printed, so this is without a > doubt a kernel bug. > > You can follow this further at > https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13834 Oh great so you were able to reproduce it. how does tearing work actually? So the game is being render using DGPU but the DRM for tearing is handle by IGPU? And also when we were testing 4800! Tearing was working. > So the game is being render using DGPU but the DRM for tearing is handle by IGPU? Yes, presentation happens on the internal GPU in this case. > And also when we were testing 4800! Tearing was working. The merge request initially had a way more complicated approach, which skipped the cursor plane entirely once it was disabled, and accidentally worked around this bug. Now KWin tells the kernel every frame that it is not using the cursor plane (as it's supposed to!), and that seems to trigger the issue. Got it, maybe that's why when I have allow tearing application on, the application doesn't use direct scannout, The Compositing red text is shown. But thanks for finding out the issue, hope so it get fixed. Any update on this issue? No, it's still a driver bug that has to be fixed in the driver. Is there any way I can test that patch? I tried building kernel with that patch. but am still getting [ 194.502884] i915 0000:00:02.0: [drm:drm_atomic_set_property] [PLANE:129:cursor B] does not support async flips and Presentation mode doesn't change to VRR (In reply to Syntist from comment #14) > Is there any way I can test that patch? I tried building kernel with that > patch. but am still getting > > [ 194.502884] i915 0000:00:02.0: [drm:drm_atomic_set_property] > [PLANE:129:cursor B] does not support async flips > > and Presentation mode doesn't change to VRR Sorry Tearing* Should it only affect Intel GPUs? I can't get tearing working on AMD GPU either. (In reply to Oleg from comment #16) > Should it only affect Intel GPUs? I can't get tearing working on AMD GPU > either. Am not sure, I am not able to get tearing working on Intel GPU, not sure about nvidia, because my nvidia is only being used for offloading, the screen and everything else is being render by iGPU (In reply to Oleg from comment #16) > Should it only affect Intel GPUs? I can't get tearing working on AMD GPU > either. It's a kernel regression, see https://gitlab.freedesktop.org/drm/amd/-/issues/4263 |