Bug 48458

I can confirm the exact same behavior.  I happen to be trying to do the same thing with, as luck would have it, 1920x1080 monitors and two ATI cards as well (Radeon X1300/X1550 and Radeon HD 5450).  My X.Org X server version is 1.11.3, release date 2011-12-16 (the current latest from Ubuntu 12.04 repos).

I can also confirm that the culprit is the combination of Xinerama and rotation.  When the mouse moves below pixel 1080, which would have been the un-rotated bottom of the screen, X kicks in a sliding viewport that's unnecessary and shifted to the right by about 1080 pixels as well.  I think some code isn't picking up on the rotation and is using the wrong dimension in the math.  I've tried configuring the viewport explicitly, but haven't been able to hit upon a set of options that will do it correctly.  Note that the viewport appears to work perfectly (no viewport/same as screen) so long as you stay in the top 1080 pixels.  It's only when you mouse down past 1080 that the viewport suddenly activates.

Sounds like a weird edge case in RandR/Xinerama interaction to me...

Hi,

I've run into the same problem, when setting up triple-head using two separate video cards and Xinerama.

It seems that the source of the problem is that Xrandr is responsible for handling the rotation, but it's not really fully enabled.  In particular the xf86RandR12Init12 function doesn't get called in Xinerama mode, which means
that pScrn->PointerMoved stays at its default (xf86PointerMoved), which doesn't understand rotation.

I made the below change to Debian's xserver-xorg-core package, which just disables the panning entirely.  Not the correct fix obviously, but it works for use cases like ours:

--- xorg-server-1.12.3/hw/xfree86/common/xf86Cursor.c   2012-07-08 20:32:59.000000000 -0400
+++ xorg-server-1.12.3-jim/hw/xfree86/common/xf86Cursor.c       2012-07-27 19:10:28.000000000 -0400
@@ -142,10 +142,12 @@
 xf86PointerMoved(int scrnIndex, int x, int y)
 {
     Bool frameChanged = FALSE;
     ScrnInfoPtr pScr = xf86Screens[scrnIndex];
 
+    return;
+
     /*
      * check wether (x,y) belongs to the visual part of the screen
      * if not, change the base of the displayed frame accoring
      */
     if (pScr->frameX0 > x) {

With X.Org X Server 1.13.0 and xf86-video-ati-6.14.6,
the problem is still there.
(I currently have a single rotated (right) monitor on the second Radeon HD 5750,
 which becomes unusable under Xinerama due to this problem:
 As soon as the mouse enters that monitor from the right, the viewport
 shifts right by presumably (1920 - 1080 = 840) pixels,
 so that only a slice 240 pixels wide remains visible (the rest disappears).
 There seems to be no way to make this move back.
 Vertical movement of the mouse makes this slice additionally pan upwards
 by up to 840 pixels; this also can pan vertically back into place.)

Any news on that subject?
This bug is really annoying.

Is this a Ati/AMD specific issue. (?)
I just see Ati/AMD configurations here. 
Not sure what Jim Paris uses, though.

I can confirm: On the same machine a xinerama setup showed the described behaviour with an Ati X300SE GPU but worked flawless on the intel 965 IGP.

Why is this low importance? The bug makes the desktop unusable.

Created attachment 105589 [details]
Xorg log file

ping...

This bug still exists (using latest Debian/Jessie).
I have a similar setup: 4 TFTs whereof 2 are rotated. 

The card is an ATI FireMV 2450, which shows up as two devices:
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 95cd
04:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Device 95cd

Is anyone working on this?
Or is there at least some kind of workaround available?

Ugly "fix" at the moment: Switch to console and back...

Btw, randr is not an alternative (to xinerama) since it doesn't seem to work with rotated screens on two combined GPUs (error: "Cannot do multiple crtcs without X server dirty tracking 2 interface").

(Added my log file)

I have the same problem, 
Disabling xinerama removes the problem for me, but then introduces new problems, because you can't  move windows around without it.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/238.