Bug 467771 - Wayland screen corruption, dual output, dual GPU, different screen resolution
Summary: Wayland screen corruption, dual output, dual GPU, different screen resolution
Status: RESOLVED DUPLICATE of bug 469623
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (other bugs)
Version First Reported In: 5.27.3
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-03-25 10:03 UTC by Stefan Hoffmeister
Modified: 2023-08-28 19:18 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Screen content corruption (158.25 KB, image/png)
2023-03-25 10:03 UTC, Stefan Hoffmeister
Details
drm_info output of system affected (389.70 KB, text/plain)
2023-03-25 11:17 UTC, Stefan Hoffmeister
Details
picture of corruption (1.43 MB, image/jpeg)
2023-04-13 02:53 UTC, Matt Keith
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Hoffmeister 2023-03-25 10:03:14 UTC
Created attachment 157562 [details]
Screen content corruption

KDE / Wayland seems to reliably get confused about which screen is attached to which output in a multi-GPU setup.

This materializes in bad / wrong / missing invalidation of painting areas, leaving content garbage in place, and also results in "impossible" state where Spectacle as a screenshotter claims part of a very much existing screen as _transparent_.

The attached screenshot shows the broken state; notice
* the red frame I painted in to show the middle screen ("screen #2") in a triple screen setup
* the bottom-right corner of screen #2, which Spectacle sees as transparent - but which it is not
* the corruption elsewhere on screen #2

Now particularly note the "clean" area on screen #2 - the dimensions here are exactly the same as the dimensions of the screen to the left ("screen #3").

AFAICT, this implies that KWin incorrectly uses the dimensions of screen #3 to compute damage / paint / invalidation areas on screen #2. This then leads to garbage artefacts on the (larger) screen #2.

Key to reproducing this probably is, unfortunately, a GPU setup where

* iGPU = Intel
* dGPU = Nvidia

and where

* screen #1 == laptop == Intel (right-most screen)
* screen #2 == HDMI port _connected to Intel_
* screen #3 == DisplayPort port _connected to NVIDIA_

and where I used "KWIN_DRM_DEVICES=/dev/dri/card1:/dev/dri/card0" to force the NVIDIA GPU as the primary GPU (without this forcing, the Intel GPU becomes primary)

There is no internal mux on the notebook; the outputs are hardwired. In that setup, the NVIDIA card draws everything, draws natively on screen #3, and passes data for screen #2 and screen #1 to the Intel GPU for output.

*******

For the sake of disclosure, the screenshot comes from a bit of additional peculiar set of steps - but it highlights much better the exact same effect seen during "normal operations" with the above setup: The damage / paint area when drawing on screen #2 is taken from screen #3.

The peculiarity is physically turning off screen #3 (the left-most screen), and the Thunderbolt docking station apparently keeps some kind of connection alive, which results in screen #3 still being "seen". But again, I see structurally the same corruption if I don't do that - it's just so much more evident with that peculiar step.

I have no idea why I never see corruption on screen #1 or screen #3.
Comment 1 Stefan Hoffmeister 2023-03-25 11:17:57 UTC
Created attachment 157564 [details]
drm_info output of system affected

Added drm_info output which might be more effective in communicating the setup than prose.
Comment 2 Stefan Hoffmeister 2023-03-25 11:27:10 UTC
Note: _drawing_ something that is "alive" works just perfectly fine - so putting real content into those affected areas renders just fine.

It's, for whatever reason, only whenever content is _not_ painted there that the corruption becomes visible.

Leaving, say, a Youtube video playing in the affected areas (i.e. continuous refreshing of that area) results in no corruption. Leaving an empty / idle Kate window in that exact same area will also result in screen corruption over that area, until (in this example) the Kate window gets repainted.
Comment 3 Stefan Hoffmeister 2023-04-12 18:16:47 UTC
https://www.reddit.com/r/Fedora/comments/12j8j1n/have_you_guys_seen_this_screen_glitch_in_kde_what/?utm_source=share&utm_medium=web2x&context=3 looks interesting and possibly related - the symptoms are very similar.

Note that the Reddit thread talks about an AMD RX5700 eGPU, attached to a laptop.
Comment 4 Matt Keith 2023-04-13 02:53:52 UTC
Created attachment 158056 [details]
picture of corruption

attachment showing my occurrence. the top left seems to work reliably and is about the size of my laptops display
Comment 5 Matt Keith 2023-04-13 02:54:32 UTC
(In reply to Stefan Hoffmeister from comment #3)
> https://www.reddit.com/r/Fedora/comments/12j8j1n/
> have_you_guys_seen_this_screen_glitch_in_kde_what/
> ?utm_source=share&utm_medium=web2x&context=3 looks interesting and possibly
> related - the symptoms are very similar.
> 
> Note that the Reddit thread talks about an AMD RX5700 eGPU, attached to a
> laptop.

Hi, I am the reddit poster here. about info below:
Operating System: Fedora Linux 37
KDE Plasma Version: 5.27.4
KDE Frameworks Version: 5.104.0
Qt Version: 5.15.8
Kernel Version: 6.2.9-200.fc37.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 20 × 12th Gen Intel® Core™ i7-1280P
Memory: 62.5 GiB of RAM
Graphics Processor: AMD Radeon RX 5700
Manufacturer: Framework
Product Name: Laptop (12th Gen Intel Core)
System Version: A8

I am happy to provide any debug info that would be useful. This happens just about every time I use my computer so I can reproduce it easily
Comment 6 Zamundaaa 2023-08-28 19:16:11 UTC
*** Bug 473736 has been marked as a duplicate of this bug. ***
Comment 7 Zamundaaa 2023-08-28 19:18:54 UTC

*** This bug has been marked as a duplicate of bug 469623 ***