Created attachment 122630 [details] [review]
Update pixmap pitch in radeon_set_pixmap_bo

Does this patch fix the problem? If not, please attach the Xorg log and the output of xrandr captured when the problem occurs.

(In reply to alex_y_xu from comment #0)
> I can bisect if necessary, but it would be somewhat inconvenient.

Why is that? FWIW, you don't even need to quit your main X session for it.

> I would prefer a specific commit to checkout or revert to test.

My guess would be that https://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=b2b079be0e7ef2704c3df9ee25fe46166e450e83 introduced the problem.

(In reply to Michel Dänzer from comment #1)
> Created attachment 122630 [details] [review] [review]
> Update pixmap pitch in radeon_set_pixmap_bo
> 
> Does this patch fix the problem? If not, please attach the Xorg log and the
> output of xrandr captured when the problem occurs.

Oh, I forgot to attach Xorg log. I checked xrandr and the output appeared to be correct. I also did "xrandr --output DVI-1 --off" which turned the monitor off, then "xrandr --auto DVI-1" which turned it back on with the same issue.

Also, in case it is relevant, the corruption looks similar to blocks of the previous content displayed on the screen. Also, as far as I can tell, the cursor works normally when moved over into that monitor (i.e. displayed "on top" of the corruption), including being Plasma themed. Also, unsurprisingly, spectacle (KDE screenshot utility) displayed the contents of the monitor correctly.

> (In reply to alex_y_xu from comment #0)
> > I can bisect if necessary, but it would be somewhat inconvenient.
> 
> Why is that? FWIW, you don't even need to quit your main X session for it.

Hm, I forgot about that. Still, I would have to figure out how the ebuild works or how to install the driver myself. Not a huge amount of work, but I assumed you can probably accurately guess the problem.

> > I would prefer a specific commit to checkout or revert to test.
> 
> My guess would be that
> https://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/
> ?id=b2b079be0e7ef2704c3df9ee25fe46166e450e83 introduced the problem.

OK, I can test in ~18 hours.

(In reply to alex_y_xu from comment #2)
> > My guess would be that
> > https://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/
> > ?id=b2b079be0e7ef2704c3df9ee25fe46166e450e83 introduced the problem.
> 
> OK, I can test in ~18 hours.

Please try the patch first though, and if it fixes the problem with glamor, please check that EXA still works correctly as well.

(In reply to Michel Dänzer from comment #3)
> (In reply to alex_y_xu from comment #2)
> > > My guess would be that
> > > https://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/
> > > ?id=b2b079be0e7ef2704c3df9ee25fe46166e450e83 introduced the problem.
> > 
> > OK, I can test in ~18 hours.
> 
> Please try the patch first though, and if it fixes the problem with glamor,
> please check that EXA still works correctly as well.

Yes, both work OK now with TearFree enabled. I didn't try turning off TearFree with either AccelMethod.

Thanks for the report and testing. Fixed in Git master:

commit 83734317e6bdaeebb4462a63f541e73a1d7c2f77
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Mar 30 11:44:09 2016 +0900

    Update pixmap pitch in radeon_set_pixmap_bo

This fix leads to the following error on my system:

[   11.986429] radeon 0000:00:01.0: evergreen_surface_check_linear_aligned:215 texture pitch 1680 invalid must be aligned with 64
[   11.986443] radeon 0000:00:01.0: evergreen_cs_track_validate_texture:830 texture invalid 0x1a3c3441 0x10000419 0x060a0000 0x00000000 0x00000004 0x8002001a
[   11.986453] [drm:radeon_cs_ioctl] *ERROR* Invalid command stream !

It's happening when starting sddm and everytime logging out and sddm takes over again.

hardware is AMD/ATI BeaverCreek [Radeon HD 6530D]

native resolution 1680x1050

Johannes, please use bug 94901 for your issue.