Bug 584927

Summary:	Problems with cursor movement when Xinerama layout is out of order
Product:	Red Hat Enterprise Linux 6	Reporter:	Daniel Dadap <ddadap>
Component:	xorg-x11-server	Assignee:	Adam Jackson <ajax>
Status:	CLOSED CURRENTRELEASE	QA Contact:	desktop-bugs <desktop-bugs>
Severity:	high	Docs Contact:
Priority:	urgent
Version:	6.0	CC:	agittins, aplattner, cmeadors, friz, jkachuck, kevin.wilson, tao, vbenes
Target Milestone:	rc	Keywords:	Triaged
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	xorg-x11-server-1.7.7-1.el6	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-11-10 21:57:52 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Daniel Dadap 2010-04-22 18:14:16 UTC

Description of problem:
If a Xinerama layout is created where a higher numbered display is placed anywhere besides to the right of a lower numbered display (in other words, to the left of, above, or below) then trying to move the cursor from the lower numbered display to the higher numbered display with out of order placement will cause the cursor position to be incorrectly displayed.

Version-Release number of selected component (if applicable):
1.7.5

How reproducible:
Any Xinerama layout with out of order positioning should reproduce this problem.

Steps to Reproduce:
1. Create a Xinerama layout with two screens. Position screen 0 on the right and screen 1 on the left.
2. Move the cursor from screen 0 to screen 1.
3. Observe cursor movement as the cursor crosses over.
  
Actual results:
Once the cursor crosses over to screen 1, it will rapidly oscillate over a range of positions. The size of this range depends on cursor velocity when it crossed over. You should be able to move the cursor back to screen 0.

Expected results:
The cursor should move normally between screens, the same way it does if screen 0 is on the left and screen 1 is on the right.

Additional info:
This is a known regression in upstream X.org, but if RHEL6 is to ship with this regression, it will negatively impact a huge number of customers using Xinerama. See freedesktop.org bug below:

http://bugs.freedesktop.org/show_bug.cgi?id=24986

Comment 2 RHEL Program Management 2010-04-22 20:13:47 UTC

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 3 Kevin 2010-04-23 17:55:57 UTC

This bug must also apply to Fedora 12. Having my second monitor "leftof" of primary monitor in F11 worked fine. After upgrading to F12 via preupgrade my mouse will no longer travel to the second monitor with Xinerama enabled. If I disable Xinerama in xorg.conf the mouse will then travel to the second monitor.

I am looking for a clone of this bug opened against Fedora 12. If I cannot find one that applies I will clone this bug to create a new report.

Thanks

Comment 4 Ashley Gittins 2010-04-24 03:31:04 UTC

This would appear to be the same issue noted in the now two-month old bug 567835 filed against F12. Props to Kevin for making the link.

Since the issue often (on my F12 system at least) leads to an unusable X session should it qualify for a higher priority than "low"?

Comment 5 Kevin 2010-04-25 16:53:30 UTC

The simple workaround to have dual monitors, F12 & an nvidia card is to change secondary monitors position in your server layout directive to "RightOf" (mine was using LeftOf). Do this and everything will work fine for a simple dual monitor setup.

The only thing left is the SIGTERM you now get in F12 when the xorg-nvidia driver is loaded.

Comment 6 Ashley Gittins 2010-04-26 22:49:56 UTC

@ comment #5 yes, that does work for a simple dual-monitor setup, but it is just a workaround as you said. It means you end up with your fullscreen OpenGL, login box and other 'default screen' stuff happening on the display you didn't want it on which can be an issue if the displays are different sizes or otherwise awkward to use in that configuration.

I've been putting up with my left screen being rightOf my right screen for months now just so I could keep my gaming on the centre screen. It's wonderfully mind-bending to have to keep pushing the pointer to the right as you turn your head to the left, then wondering why you can't escape the left monitor until you realise you need to move "more left" :-)

As far as I know there is no way currently to repair this behaviour with config tweaks, having a display left of the primary display is simply broken.

(sorry for duplicate reply to duplicate comment, but unsure if these two bugs would end up being merged and therefore where the discussion should be).

Comment 9 Adam Jackson 2010-05-25 14:11:17 UTC

Looks backportable from master, devel ack.

Comment 11 Jason Frisvold 2010-05-26 15:36:39 UTC

This problem exists in Fedora 13 as well, despite xorg being updated to 1.8.0.  The "fixed" xorg release is apparently 1.8.0.901.  The original poster has a link to the upstream bug and ultimate fix.  It would be nice to see this fixed as moving the pointer off the right edge of my screen to get to my upper monitor is a bit counter-intuitive..  :)

Comment 13 Vladimir Benes 2010-08-31 09:43:29 UTC

it seems to be fixed as no strange movements are present and moving from one screen to another works in top/down, left/right and corner-connected positions
-> VERIFIED

Comment 14 releng-rhel@redhat.com 2010-11-10 21:57:52 UTC

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.