Created attachment 123886 [details]
chromium right click
With DRI3 set as default in radeon driver, screen corruption appears in plasma taskmanager, system tray widgets and firefox&chromium right click menus.
DRI3 with glamour doesn't have this corruption, only EXA and XAA.
Corruption also happens if desktop effect are disabled in Kwin.
With DRI2 enabled, rendering is bug free.
This is rather old laptop graphics VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV530/M56-P [Mobility Radeon X1600].
Using glamour is not an option since it is slower and results in higher graphics card temperatures.
Kernel is 4.5, Xorg-server 1.18.3, gentoo linux.
Created attachment 123887 [details]
firefox right click
Created attachment 123888 [details]
system tray popup widgets
Created attachment 123889 [details]
taskbar with chromium as main window
Created attachment 123890 [details]
taskbar with empty desktop
Does the patch attached to bug 94901 help by any chance? If not, please attach the Xorg log file and output of dmesg.
I already have that patch applied and it fixed pre sddm screen corruption. Without patch everything looks fine once sddm login is available.
Created attachment 123931 [details]
Created attachment 123932 [details]
And I'm using EGL in KWIN.
(In reply to Ivan Majhen from comment #6)
> Without patch everything looks fine once sddm login is available.
Are you saying the problem described in this report doesn't happen without the patch?
Problem happens with/without patch. My bug is different than #bug 94901.
Was this problem already present with xf86-video-ati Git commit 64e1e4db ("Add DRI3 support v2"), which was when DRI3 support was initially added? Note that this commit will only recognize Option "DRI3", not the current variant Option "DRI" "3".
I always had glitches with dri3. I tested it about 30 times in the past year.
Commit 64e1e4db didn't compile. First commit that compiles with current setup is https://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=b16609b453bb1a181198cf27778f205dc23fb642
It doesn't compile cleanly.
/usr/src/portagetmp/portage/x11-drivers/xf86-video-ati-9999/work/xf86-video-ati-9999/src/radeon_kms.c: In function ‘redisplay_dirty’:
/usr/src/portagetmp/portage/x11-drivers/xf86-video-ati-9999/work/xf86-video-ati-9999/src/radeon_kms.c:284:2: error: too many arguments to function ‘PixmapSyncDirtyHelper’
error: too few arguments to function ‘PixmapStartDirtyTracking’
PixmapStartDirtyTracking(ppix, screenpix, 0, 0);
changed to PixmapStartDirtyTracking2 in drmmode_display.c
After that enabled DRI3 and got completely corrupted screen.
Screenshot and xorg.log attached.
Created attachment 124081 [details]
Created attachment 124082 [details]
old xorg log driver with dri3 enabled
Created attachment 124202 [details] [review]
Always call exaMoveInPixmap in radeon_dri3_fd_from_pixmap
Does this patch fix the problem?
It doesn't fix anything.
Window previews are now almost always empty with transparent background.
If desktop has windows, tooltips on desktop switcher are fine.
Clock widget tooltips and Application launcher tooltips are always fine, systray is completely broken, except tooltips on clipboard.
Chromium and Firefox right click menu is still broken.
Created attachment 124209 [details]
tooltips and widgets not updating
*** Bug 96960 has been marked as a duplicate of this bug. ***
I looked into this issue, and I'm afraid it's probably unfixable due to the way EXA works. So I changed the driver to no longer enable DRI3 by default with EXA as of the commit referenced below.
Author: Michel Dänzer <firstname.lastname@example.org>
Date: Tue Jul 12 17:36:27 2016 +0900
Don't enable DRI3 by default with EXA
To elaborate on comment 21:
The problem is that DRI3 can be used as a general buffer sharing mechanism. The shared buffers can be used like any other pixmap in X, and the client can also do whatever it wants with them on the client side.
EXA doesn't know that these pixmaps are shared with the client, so its tracking of valid pixmap contents gets confused, and it ends up using stale contents. I believe this is unfixable with the current EXA design because in contrast to DRI2, there is no clearly defined flow of data between client and server side.