Bug 440852 - Black or vertically mirrored window with some XWayland apps on nvidia 470+ drivers
Summary: Black or vertically mirrored window with some XWayland apps on nvidia 470+ dr...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: 5.22.4
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-08-11 00:53 UTC by Marcelo Bossoni
Modified: 2021-08-25 12:52 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Full black window on steam app (17.09 KB, image/png)
2021-08-11 01:00 UTC, Marcelo Bossoni
Details
Upside down window content (1.11 MB, image/png)
2021-08-11 01:01 UTC, Marcelo Bossoni
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marcelo Bossoni 2021-08-11 00:53:57 UTC
SUMMARY



STEPS TO REPRODUCE
1. Open a XWayland app like Steam
2. Resize it
3. Minimize and Maximize it

OBSERVED RESULT
After 1: Window is black
After 2: Window content is upside down
After 3: Window is correct


EXPECTED RESULT
Window is always correct

Operating System: Arch Linux
KDE Plasma Version: 5.22.4
KDE Frameworks Version: 5.84.0
Qt Version: 5.15.2
Kernel Version: 5.13.9-zen1-1-zen (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 1600 Six-Core Processor
Memory: 15.6 GiB of RAM
Graphics Processor: NVIDIA GeForce GTX 1070/PCIe/SSE2

ADDITIONAL INFORMATION
Comment 1 Marcelo Bossoni 2021-08-11 01:00:46 UTC
Created attachment 140648 [details]
Full black window on steam app
Comment 2 Marcelo Bossoni 2021-08-11 01:01:16 UTC
Created attachment 140649 [details]
Upside down window content
Comment 3 Nate Graham 2021-08-11 14:52:12 UTC
yikes!
Comment 4 mouacyk 2021-08-19 14:15:09 UTC
Also any xwayland game opened in fullscreen is black. Windowed mode renders fine.
Comment 5 Zamundaaa 2021-08-19 16:07:37 UTC
Can someone verify if git master is also affected?
Comment 6 Marcelo Bossoni 2021-08-19 17:50:38 UTC
Any easy way to do that on Arch?
I mean, should I replace all kde packages or just kwin?
Comment 7 Zamundaaa 2021-08-20 16:29:55 UTC
You can either replace KWin and dependencies (you'll need at least kwayland-server and kdecoration, probably more though) which could cause breakage, or use kdesrc-build (https://community.kde.org/Get_Involved/development#Set_up_kdesrc-build) to build everything needed locally.
Comment 8 Marcelo Bossoni 2021-08-20 23:33:50 UTC
Just built everything using kdesrc-build
This bug seems fixed using that version.

There are some other small bugs like lamp animation during maximize seems borked on firefox
trying to move an mpv window glitches it

but no black screen.
Comment 9 Bug Janitor Service 2021-08-25 12:34:57 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1297
Comment 10 Zamundaaa 2021-08-25 12:52:55 UTC
Git commit 9056eccd6241223b36d899357680acd52ac68804 by Xaver Hugl, on behalf of Erik Kurzinger.
Committed on 25/08/2021 at 12:32.
Pushed by zamundaaa into branch 'Plasma/5.22'.

platforms/drm: check wl_eglstream buffers before attaching

If a wl_eglstream buffer is attached to a surface, but then later a different
type of buffer, such as a dmabuf, is attached to the same surface, kwin will
mistakenly keep trying to acquire frames from the EGLStream associated with the
previous buffer. This can happen if an Xwayland window is made full-screen
causing it to switch to the flipping presentation path, for instance. The
result is that the window contents will no longer be updated.

Instead, the eglstream backend's loadTexture and updateTexture functions should
first pass the buffer to eglCreateStreamAttribNV. If it fails with
EGL_BAD_STREAM_KHR, that indicates it is indeed a wl_eglstream, and that we've
already associated a server-side EGLStream with it in attachStreamConsumer, so
we can proceed as usual. If it fails with EGL_BAD_ACCESS, though, that
indicates it is not a wl_eglstream and we should fall back to the parent class
which handles attaching other buffer types. If it doesn't fail at all, that
means the client tried to attach a new wl_eglstream to a surface without first
attaching the stream consumer. There's not really a great way to handle this,
so just re-use the previous EGLStream.

(cherry picked from commit 770875a76e662a1ed7728da769f8f7d019623701)

M  +41   -5    src/plugins/platforms/drm/egl_stream_backend.cpp
M  +4    -0    src/plugins/platforms/drm/egl_stream_backend.h

https://invent.kde.org/plasma/kwin/commit/9056eccd6241223b36d899357680acd52ac68804