It seems that if I only rotate one screen then the screen not rotated does not update anymore (except for the mouse cursor, which changes according to what is below it). To test this I run: xrandr --output DVI-1 --auto --rotate left --output DVI-0 --auto --primary That makes DVI-0 stop updating (sometimes most part of an app is grey, or something else, but it keeps the same and is never updated). DVI-1 rotates and works as expected. To restore a working desktop on DVI-0 I run: xrandr --output DVI-1 --rotate normal Both screens update if I rotate both: xrandr --output DVI-1 --auto --rotate left --output DVI-0 --rotate left --auto --primary Hardware: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti XT [Radeon HD 7970/R9 280X] Software: Linux kernel 3.19.1 + fix_to_test patch from https://bugs.freedesktop.org/show_bug.cgi?id=89505 xorg-server 1.17.1 I am happy to test patches and report back.
Two new data points: I tried on another computer with xorg-server 1.15.0 and glamor 0.5.1 and there it worked. I upgraded libdrm, xf86-video-ati and glamor to newest git (not the one included in the xorg-server). And then I got the same problem again. Also what type of rotation used matters, as I mentioned previously if I used the same rotation on both outputs it worked. But now I also note that if you can use left and right together and normal and inverted together. In other words: xrandr --output DVI-1 --auto --rotate left --output DVI-0 --rotate right --auto --primary xrandr --output DVI-1 --auto --rotate right --output DVI-0 --rotate left --auto --primary xrandr --output DVI-1 --auto --rotate normal --output DVI-0 --rotate inverted --auto --primary xrandr --output DVI-1 --auto --rotate inverted --output DVI-0 --rotate normal --auto --primary Also, tried with three monitors, then DVI-1 and HDMI-0 has to have the same rotation pairs (left/left, left/right, right/right, normal/normal, normal/inverted and inverted/inverted).
(In reply to Asbjørn Sannes from comment #1) > Two new data points: > > I tried on another computer with xorg-server 1.15.0 and glamor 0.5.1 and > there it worked. I upgraded libdrm, xf86-video-ati and glamor to newest git > (not the one included in the xorg-server). And then I got the same problem > again. Can you narrow down which component and bisect?
Think I have narrowed it down to xf86-video-ati, found a good commit and a bad one and bisected to: e4cd0f4392ea11c93088ad429f36eaaf9bcbf505 is the first bad commit commit e4cd0f4392ea11c93088ad429f36eaaf9bcbf505 Author: Alex Deucher <alexander.deucher@amd.com> Date: Wed Oct 30 15:21:26 2013 -0400 radeon: enable tiling on SI by default (v2) Now that mesa 9.2 is out with support for tiling on SI asics, we can enable it here. Tiling improves memory bandwidth utilization. V2: update man page Signed-off-by: Alex Deucher <alexander.deucher@amd.com> :040000 040000 73cb41fdb12a13eb1844672f43bd06d57b13a661 fc69858d6365cca340241f1372b818abfc84405d M man :040000 040000 0ffa685af2e29defb896795d3542d3fe2da82561 8d09649318c53da1cac642bc79588b2323947086 M src Also running latest git of xf86-video-ati with that reverted also fixes it. I am going to try it on another box with a newer stack to see if setting ColorTiling2D to off helps there aswell.
Using unmodified xf86-video-ati (git) with: Section "Device" Identifier "open" Driver "radeon" Option "ColorTiling2D" "Off" EndSection Makes it work.
I thought it was working quite nicely with Option "ColorTiling2D" "Off", but now I actually experienced the same problem again with it "Off". Also it is the exact opposite, it now only corrupts the screen if it is in normal rotation and not left. I am a bit puzzled to say the least, but maybe you can make more sense out of it?
Updated to the latest git of the different versions, and now the behaviour is completly different, instead of stopping to update the other screen, the rotated screen is no longer lighting up. The behaviour seems random to me.
Does this still happen with current xf86-video-ati Git master? This might fix it: http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=ce9914af8d8d5243977023ec7b09c605f9cca8b4
I have the same problem, rotate my 2nd screen in Ubuntu Wily and the screen corrupts. compiled the latest from xf86-video-ati but it doesn't fix the problem. installed the Vivid debs: xserver-xorg-video-ati_1%3a7.5.0-1ubuntu2_amd64.deb xserver-xorg-video-radeon_1%3a7.5.0-1ubuntu2_amd64.deb and they work.
(In reply to Lee Donaghy from comment #8) > I have the same problem, rotate my 2nd screen in Ubuntu Wily and the screen > corrupts. Please file your own report for now, including the corresponding Xorg.0.log file. > installed the Vivid debs: > xserver-xorg-video-ati_1%3a7.5.0-1ubuntu2_amd64.deb > xserver-xorg-video-radeon_1%3a7.5.0-1ubuntu2_amd64.deb > > and they work. Can you bisect xf86-video-ati Git?
(In reply to Michel Dänzer from comment #7) > Does this still happen with current xf86-video-ati Git master? This might > fix it: > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/ > ?id=ce9914af8d8d5243977023ec7b09c605f9cca8b4 Sorry for the delay, have been abroad. Also recent kernels does not light up the display I usually test with (unrelated to this). Fortunately I have another computer I had the same issue with. And everything seems to work now. I have not tested to revert that patch to verify that it is really that commit that fixes it. Also only tested a couple of times, but I have experienced earlier that some options may mask it (or other random things). So I am going to test it more thoroughly tomorrow to make sure. tldr; It seems to work, will test more tomorrow.
Could easily reproduced the problem when I tested with patch [1] reverted. With latest git I was unable to get the problem, so for me this problem is solved on the two computers I could test on. Thank you very much, this lets me enjoy my desktop alot more! :) [1] http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/patch/?id=ce9914af8d8d5243977023ec7b09c605f9cca8b4)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.