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]
dmesg

Created attachment 123932 [details]
Xorg.log

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’
  PixmapSyncDirtyHelper(dirty, &pixregion);
  
  removed &pixregion

 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]
Old dri3

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. 

Screenshots attached.

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.

commit 94fe42f29e0b00a26e810581d6c438ac6d8ecd8a
Author: Michel Dänzer <michel.daenzer@amd.com>
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.