https://bugs.freedesktop.org/show_bug.cgi?id=89980

falaca@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Hardware|Other |x86-64 (AMD64) Version|XOrg git |unspecified OS|All |Linux (All)

https://bugs.freedesktop.org/show_bug.cgi?id=89980

--- Comment #3 from falaca@gmail.com --- Based on my debugging so far, it seems that mesa is the likely culprit.

Step #1: Fresh install of Ubuntu 14.04 (installed on a new, clean partition): Linux 3.13 kernel -> Manually upgraded to Linux 4.0 mainline Xorg 1.15.1 Mesa 10.1.3 xf86-video-ati 7.3 libdrm 2.4.56

Status: The bug is not present, and confirms that the issue is not with the kernel.

----------

Step #2: Installed Ubuntu 14.04.2 hardware enablement stack: Linux 4.0 (mainline) Xorg 1.16.0 Mesa 10.3.2 xf86-video-ati 7.4 libdrm 2.4.56

Status: The bug is present.

----------

Step #3: I reverted to the original 14.04 packages, but compiled xf86-video-ati 7.4 from git.

Status: The bug is not present, and confirms (?) that the issue is not with ddx.

----------

Step #4: I had trouble getting Ubuntu to work with Mesa compiled from git (whenever I try to log in, I just get kicked back to the lightdm greeter), and I couldn't upgrade Mesa from the Ubuntu repo without also upgrading Xorg, so I upgraded Mesa from Oibaf PPA:

Linux 4.0 (mainline) Xorg 1.15.1 Mesa 10.6 (oibaf-ppa) xf86-video-ati 7.4 (git) (also tested 7.5.99 from oibaf-ppa) libdrm 2.4.60 (oibaf-ppa)

Status: The bug is present. So it seems likely that the bug was introduced somewhere between Mesa 10.1.3 and 10.3.2.

If I can figure out how to get Ubuntu to play nice with mainline Mesa compiled from git (maybe if I figure out how to apply the Ubuntu patches), I can do a bisect, but that's where I'm stuck as of now.

https://bugs.freedesktop.org/show_bug.cgi?id=89980

--- Comment #5 from falaca@gmail.com --- Created attachment 115071 --> https://bugs.freedesktop.org/attachment.cgi?id=115071&action=edit Mesa bisect log

https://bugs.freedesktop.org/show_bug.cgi?id=89980

--- Comment #7 from falaca@gmail.com --- Created attachment 115102 --> https://bugs.freedesktop.org/attachment.cgi?id=115102&action=edit Different "checkerboard" corruption

This might be totally unrelated, but since I don't know enough to make that judgement, I thought I should share just in case (otherwise I could make a separate bug report for it).

Basically, I get intermittent checkerboard patterns which appear on my screen, as seen in the 2 screenshots I'm attaching (some areas blacked out by me for privacy). I don't know how to reproduce the patterns - they appear intermittent and seem unrelated to suspend/resume. They either look like "noise", like in the first screenshot, or they are remnants from a previous window that was open, like in the second screenshot.

Both of those screenshots are from the portrait display (unlike the behaviour from the video I posted in the original bug report, which only happens on the landscape display). I can't remember if I've seen this happen on the landscape display so far. I can keep collecting screenshots to see if it's confined to specific areas of the screen.

For what it's worth, I have used Catalyst 14.12 for a couple of months with this card, and didn't observe this type of behaviour.

https://bugs.freedesktop.org/show_bug.cgi?id=89980

--- Comment #9 from falaca@gmail.com --- (In reply to Michel Dänzer from comment #8)

(In reply to falaca from comment #0)

...

I can only reproduce this with when I have 2 displays connected. My primary screen is set to 2560x1440, and the secondary screen in portrait mode is set to 1200x1920 on the left-hand side. I have the landscape monitor centered with respect to the portrait one, so y = 240 in ~/.config./monitors.xml.

I cannot observe the bug when both screens are aligned at the top, i.e., with y=0 in ~/.config/monitors.xml.

Have you tried moving the landscape monitor to y = 0 and back to y = 240 after suspend/resume, while the session is up? Does that fix the problem, or does it stay corrupted?

I just tried right now, and it doesn't make a difference. But you know what, it turns out that it still *does* happen when y=0, it's just that it's a little less noticeable to me, e.g., I'm having trouble seeing it when maximizing a window, but I'm still seeing it happen in the menus. This is purely based on my eyesight, so it's hardly scientific, but I could make more videos if desired.

I tried to move my landscape screen further up (above the portrait one, but still overlapping, so I presume that would be y=0 for the landscape screen, but y= positive for the portrait screen). That resulted in X becoming unusable. My landscape screen turned white, and restarting X didn't make things much better - I just got an unusable tiled pattern: https://www.dropbox.com/s/sfrxv4owqchyq75/tiledpattern.jpg?dl=0

I rebooted and tried with linux 3.16, and also with Arch Linux + Gnome 3 + linux 3.19 (or maybe it was 4.0). Same result (white screen). So unfortunately I wasn't able to test out what would happen in that scenario.

Is there anybody else who can test this configuration (dual monitors with a portrait display)? It seems like it doesn't take much effort to break something.

https://bugs.freedesktop.org/show_bug.cgi?id=89980

--- Comment #11 from Marek Olšák maraeo@gmail.com --- (In reply to Michel Dänzer from comment #6)

(In reply to falaca from comment #4)

...

4a5519f1e019dbf1103e4f3abe0a695637a87518 is the first bad commit commit 4a5519f1e019dbf1103e4f3abe0a695637a87518 Author: Marek Olšák marek.olsak@amd.com Date: Mon Feb 10 01:25:54 2014 +0100

r600g,radeonsi: set correct initial domain for shared resources

Weird. Marek, any ideas?

Sorry, no. The commit just obtains the initial domain from the kernel, so that it can use it for command submission. The idea of the commit is that the driver shouldn't move imported buffers to a domain that is different from the domain where the buffer was originally created.

https://bugs.freedesktop.org/show_bug.cgi?id=89980

falaca@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED

--- Comment #13 from falaca@gmail.com --- Good news! I saw this today: http://lists.x.org/archives/xorg-driver-ati/2015-April/027345.html

So I built and installed Michel's xf86-video-ati repo and enabled TearFree in xorg.conf. The corruption is now gone - so I suppose it was simply some manifestation of tearing, but only after a suspend/resume cycle.

To test it, I installed the module, enabled TearFree, then did a suspend/resume cycle, and I couldn't observe any tearing in the global menus. So then I commented out the TearFree option in xorg.conf and restarted lightdm, and immediately started seeing the really obvious tearing in the menus like in the video I posted. As a final check, I uncommented the TearFree option and restarted lightdm again, and the tearing was gone.

Thanks Michel! And I hope the TearFree feature will eventually be extended to support rotated displays as well!