Bug 567835 - mouse input under xinerama fails for out of order screen
mouse input under xinerama fails for out of order screen
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
16
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
: Reopened
: 607701 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-02-23 22:39 EST by Anthony Symons
Modified: 2013-02-13 21:43 EST (History)
4 users (show)

See Also:
Fixed In Version: xorg-x11-server-1.8.0-17.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-02-13 21:43:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
visualisation of the working screen configuration (134.85 KB, image/png)
2010-02-28 20:47 EST, Anthony Symons
no flags Details
visualisation of the failing screen configuration (mouse cant enter left screen) (122.93 KB, image/png)
2010-02-28 20:48 EST, Anthony Symons
no flags Details
working xorg.conf (3.58 KB, text/plain)
2010-02-28 20:49 EST, Anthony Symons
no flags Details
not working xorg.conf (2.62 KB, text/plain)
2010-02-28 20:49 EST, Anthony Symons
no flags Details
/var/log/messages from working boot (59.34 KB, text/plain)
2010-02-28 21:00 EST, Anthony Symons
no flags Details
/var/log/messages from not working boot (60.45 KB, text/plain)
2010-02-28 21:01 EST, Anthony Symons
no flags Details
working config Xorg.0.log (13.80 KB, text/plain)
2010-02-28 21:04 EST, Anthony Symons
no flags Details
not working Xorg.0.log (13.72 KB, text/plain)
2010-03-01 00:29 EST, Anthony Symons
no flags Details

  None (edit)
Description Anthony Symons 2010-02-23 22:39:06 EST
Description of problem:

This is a tricky bug to report. Im not entirely certain if Ive filed it under the correct package. The issue is that I have multiple cards with multiple displays, and when the screen from the second card is positioned to the left of the screens on the first card the display works fine, but the mouse cursor gets pushed back on to the other display whenever it trys to enter the screen.

Note that I am using the nvidia driver, however I do not think this is a x driver issue as it only occurs with xinerama enabled, and when the screen on the second card is positioned to the left of the main display. When i move the same screen to the right hand side it works fine. 

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

up to date fedora 12 as of feb-24-2010

How reproducible:

every time

Steps to Reproduce:
1. 2 nvidia video cards. 2 displays on first card, 1 display on the second.
2. configure the card with 2 displays as 'twinview' in nvidia tool, and the stand alone display as 'seperate x-screen', and select 'xinerama'
3. using the nvidia tool, move the right hand screen to the left hand side of the other two. restart. try to move mouse on to the left hand screen.
  
Actual results:
cursor is pushed back to the right hand screen, can only use apps on the left hand screen by alt+tabbing to them and using keyboard.

Expected results:
mouse to move on to left hand screen.

Additional info:
I accept that I am using an unsupported 3rd party video driver but do think this looks very much like a new issue in the f12 xinerama extension, so hope you are able to take a look at it. The same pc was working fine on fedora 11, and fedora 12 was a fresh install on to a new hard disk. I can provide more detailed information on request.
Comment 1 Matěj Cepl 2010-02-26 17:04:26 EST
Thanks for the bug report.  We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

Please attach your X server config file (/etc/X11/xorg.conf, if available), output of the dmesg command, system log (/var/log/messages), and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above.

We will review this issue again once you've had a chance to attach this information.

Thanks in advance.
Comment 2 Anthony Symons 2010-02-28 20:47:48 EST
Created attachment 396928 [details]
visualisation of the working screen configuration
Comment 3 Anthony Symons 2010-02-28 20:48:34 EST
Created attachment 396929 [details]
visualisation of the failing screen configuration (mouse cant enter left screen)
Comment 4 Anthony Symons 2010-02-28 20:49:18 EST
Created attachment 396930 [details]
working xorg.conf
Comment 5 Anthony Symons 2010-02-28 20:49:40 EST
Created attachment 396931 [details]
not working xorg.conf
Comment 6 Anthony Symons 2010-02-28 21:00:55 EST
Created attachment 396938 [details]
/var/log/messages from working boot
Comment 7 Anthony Symons 2010-02-28 21:01:37 EST
Created attachment 396939 [details]
/var/log/messages from not working boot
Comment 8 Anthony Symons 2010-02-28 21:04:12 EST
Created attachment 396940 [details]
working config Xorg.0.log
Comment 9 Anthony Symons 2010-03-01 00:29:03 EST
Created attachment 396957 [details]
not working Xorg.0.log
Comment 10 Peter Hutterer 2010-03-01 00:34:27 EST
I've seen this just the other day actually. it happens when you cross the centre of the screen or so and sometimes the mouse pointer keeps jumping ad infinitum between the two positions.
Haven't tracked it down yet though.
Comment 11 Anthony Symons 2010-03-01 00:36:43 EST
Hi Matej, have attached logs and info from working and not working states. 

I'd also like to clarify, its not quite that the mouse cant enter the left hand screen, it can enter.. but it flickers and isnt stable. I can not get it further in than about 100 pixels max. When its on that screen it is not pushed back to the right screens, but it flickers and moves which could be that its playing back the last few mouse position locations in a loop instead of the location becoming fixed so I can move it further left. If I drag it right again and fight its flickering I can get it back on to the working screens.
Comment 12 Peter Hutterer 2010-03-01 01:19:56 EST
actually, revert that. the bug I saw has to do with wacom's multi-screen handling. I cannot reproduce it with a normal mouse.

what DE do you use? gnome or kde? any specific action you need to do to trigger this case?
Comment 13 Anthony Symons 2010-03-01 01:38:04 EST
Its Gnome. 

If i move the screen on the second card to the left hand side of the screens on the first card it occurs when the mouse moves off the left of the first physical screen on to the first logical screen.
Comment 14 Anthony Symons 2010-03-01 01:42:50 EST
Additionally I just noticed if I dont enable xinerama with the broken config then the troublesome screen doesnt get a picture either - but the mouse can still move there and presumably has the same trouble in that space. With xinerama enabled it does get a picture, but the input is still foobar. 

Same everything, screen from second card to the right of the first screens like im running now, works fine. I gather something deep inside X is making a false assumption that the first card is logical pixel 0 and that code is under running. Still I wouldnt know! :) 

Problem hardware/software config was working fine in fedora 11.
Comment 15 Ashley Gittins 2010-03-02 22:40:04 EST
I am seeing the same issue here, Fedora-12, x86_64 (system has been through upgrades since FC1test1 so has much baggage).

Two GT8800's, first one with a single DFP, the second card with two. Any time I configure one of the displays on the second card to be LeftOf (either with LeftOf or with Absolute co-ords) the mouse will jump (randomly?) around the screen border if I attempt to move the mouse to the left-most screen, and X will die shortly thereafter with complaints in the log of the event queue overflowing.

Others seem to have found that it is a regression in Xorg and there is a patch which apparently resolves the issue (I have not tried it yet myself):

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

Further (prior?) discussions on the issue can be found at http://www.nvnews.net/vbulletin/showthread.php?t=140803 which includes statements from at least one person who has experienced the exact same issue using the nouvaue driver as well, so does not appear to be an nvidia.ko specific issue.
Comment 16 Anthony Symons 2010-03-02 23:41:44 EST
I just took the patch from the freedesktop thread and applied it to the current Xorg-server srpm. Its not a complete fix for me. When I move the cursor off the left of the first physical screen (resolution 1280x1920) on to the first logical the mouse cursor jumps to about x=1024 on the same screen, instead of x=1024 on the first logical screen (its a 1024x1280 res screen).
Comment 17 Anthony Symons 2010-03-02 23:48:57 EST
Errr i mistyped all those resolutions, but the concept is right. doh!
Comment 18 Peter Hutterer 2010-03-10 00:20:39 EST
Please give the scratch build under http://koji.fedoraproject.org/koji/taskinfo?taskID=2043172
a test. It contains the same patch I attached to upstream, hoping that it might solve the issue. I'm not sure if that patch has other side-effects, so please watch out for those too.
Comment 19 Anthony Symons 2010-03-10 19:56:02 EST
No fix unfortunately. The system starts up fine, all screens have picture, but the mouse wraps on the middle screen instead of entering the left hand screen when it leaves the middle display to the left.
Comment 20 Kevin 2010-04-23 14:14:58 EDT
Bug ID 584927 (https://bugzilla.redhat.com/show_bug.cgi?id=584927) Explains the problem quite well.  Anthony Symons post on "2010-03-01 01:42:50 EST" explains my situation exactly (which has me wondering why I upgraded from F11). 

Having the secondary monitor to the left of the primary prevents the mouse from traveling to the secondary monitor. Turns out that in bug 584927 that any position other than to the right will cause X to flake out.

I have a single FX5200 dual vga nvidia card connected to two 22" 1680x1050 widescreens. The secondary monitor is "leftof" the primary and is attached via a KVM switch, the primary is directly attached to the video card. 

The X server does segfault at startup but does eventually run. Glad I took a disk image before the upgrade cause if this isn't fixed real soon then I'm gonna have to revert back to F11.

It appears there are plenty of config files attached but if anyone wants my xorg.conf, logs, etc. please let me know and I will attach them.

Cheers!
Comment 21 Kevin 2010-04-25 12:54:18 EDT
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 22 Ashley Gittins 2010-04-26 18:48:29 EDT
@ comment #21 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.
Comment 23 Ashley Gittins 2010-06-13 05:08:05 EDT
The upstream bug https://bugs.freedesktop.org/show_bug.cgi?id=24986 now has a pair of patches which reportedly resolve this issue.

Is anyone able to build F12 packages using either that commit or the patches backported? Or is moving to F13 and seeking the fix from there the better path? (I don't know if F13 has the patch or not, just that it's using 1.8).

Note: this bug is still marked "New" and "Low priority", should that be updated?
Comment 24 Fedora Update System 2010-06-18 01:48:04 EDT
xorg-x11-server-1.8.0-17.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/xorg-x11-server-1.8.0-17.fc13
Comment 25 Fedora Update System 2010-06-21 09:10:20 EDT
xorg-x11-server-1.8.0-17.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update xorg-x11-server'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/xorg-x11-server-1.8.0-17.fc13
Comment 26 Yaakoub El Khamra 2010-06-25 12:52:58 EDT
*** Bug 607701 has been marked as a duplicate of this bug. ***
Comment 27 Fedora Update System 2010-06-28 13:21:11 EDT
xorg-x11-server-1.8.0-17.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 28 Anthony Symons 2012-01-22 19:38:46 EST
I'd like to report that I have noticed that this bug (originally reported against fedora 12) was not completely fixed. I am still having this issue on Fedora 16, but only when the system is busy.

Eg, if I click a http link in my email on the left screen (in evolution) I get the busy mouse cursor for a couple of seconds before the link opens up in the browser on the right hand screen. While I have the busy mouse cursor I cant move the mouse cursor of the left screen, it just wraps around and around. Once the link opens in the right window and the cursor adjusts back to the pointer arrow, then the mouse position functions normally again. 

I expect the fix for this issue was correct, but also needs to be made to the busy mouse cursor code. I noticed when this was first fixed that the mouse cursor would not leave the left screen when the system was still starting up but X was active. I didnt worry about it because I figued it was to do with system start up, but now understand its the busy cursor, so can verify this has been happening since F12. 

I am also finding some other wierd mouse cursor issues with GTK3 apps, as I have reported in this bug 772144 https://bugzilla.redhat.com/show_bug.cgi?id=772144

I suspect they may be related. The mouse sub system does not seem to like this screen config! Sure I could move my screens around, but I'd prefer to see the underlaying code fixed and quality bug reports are what I try to do to contribute to Fedora. 

Thanks!
Comment 29 Fedora End Of Life 2013-01-16 20:19:46 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 30 Fedora End Of Life 2013-02-13 21:43:32 EST
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.