Bug 20334

Summary: Mouse shouldn't move into area outside the monitors
Product: xorg Reporter: Federico Mena-Quintero <federico>
Component: Server/GeneralAssignee: Federico Mena-Quintero <federico>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: high CC: adam, adrien, andreasfrische+freedesktop, bryce, calumlind, camden.lindsay+freedesktop, Dennis.Benzinger, fekepp, felix, flavio.etrusco, freedesktop-bugs, freedesktop-bugzilla, gdi2k, guillaume.desmottes, lecotegougdelaforce, leho, mcepl, mike, myxal.mxl, nicolas, norman, rah, samtygier, sflaniga, stapostol, thomas.jones, tiagomatos, v.ondruch, wolfram
Version: git   
Hardware: All   
OS: All   
See Also: https://launchpad.net/bugs/389519
Whiteboard:
i915 platform: i915 features:

Description Federico Mena-Quintero 2009-02-26 11:03:29 UTC
When you have a dual-monitor setup, with monitors of different resolutions (A
and B):

    +===========+=========+
    |           |         |
    |    A      |    B    |
    |           +=========+
    |           |    C
    +===========+


Then if the mouse is in B, and you move it down, the mouse doesn't stop at the
bottom edge of B.  Instead, it "disappears" in what would be the rectangle C.

The mouse should stop at the edges of monitors instead of disappearing into the
larger virtual rectangle.

I know that RANDR 1.3 introduces panning, but if you don't use panning, the mouse should still not be able to go into the "invisible" area.

There is xserver/randr/rrpointer.c:RRPointerToNearestCrtc(); that's the "where
should the pointer go if it moves outside all the active monitors?" function, but it never gets called from anywhere (it's not unreachable code, it's just not ever called anywhere in the source).

This started as https://bugzilla.novell.com/show_bug.cgi?id=394805, and is also associated to http://bugzilla.gnome.org/show_bug.cgi?id=345155
Comment 1 Rui Tiago Matos 2009-03-07 08:51:56 UTC
This issue was discussed 2 years ago. Started with

http://lists.freedesktop.org/archives/xorg/2007-March/022979.html

and then continued in April from

http://lists.freedesktop.org/archives/xorg/2007-April/022997.html

onwards. The agreement seems to be that it should be configurable by some agent in the user session. So, new protocol must defined.

Various issues must be considered, including:

* isolated CRTCs - not sharing any border with any other one

* overlapping CRTCs

* interaction with panning

* interaction with CRTC transforms

* interaction with multi pointer

All things considered, seems like real fun :-)
Comment 2 Bob Ham 2009-05-16 11:11:20 UTC
From http://lists.freedesktop.org/archives/xorg/2007-April/023004.html :

"I don't think I've seen many user complaints from that."

*complain*
*complain*
*complain*
Comment 3 Christoph Brill 2009-06-22 14:40:31 UTC
I'd like to complain, too.

I'm running a laptop which is smaller in height then the attached TFT and I see exactly the same issue. My colleagues running Vista laugh at me ;-) It's a real no-go for average users.
Comment 4 Dennis Benzinger 2009-06-27 11:27:40 UTC
*complain*

It works on Mac OS X and Windows. It would be nice if xorg would at least work
in the easy case described in this bug report. I don't think the case of isolated CRTCs is important.
Comment 5 Thomas Jones 2009-06-29 13:52:53 UTC
This drives me nuts since my XFCE panel is set to autohide at the bottom of the screen (the shorter of two screens) and getting the mouse into a position that will cause it to show is irritating and sort of defeats the purpose of my putting it where it was (so it's got 'infinite' height)
Comment 6 Peter Hutterer 2009-07-15 21:23:22 UTC
*** Bug 22750 has been marked as a duplicate of this bug. ***
Comment 7 gdi2k@gmx.net 2009-09-06 16:15:20 UTC
*complain*

Also annoying is the fact that window title bars can be dragged into this dead space, meaning it's possible to actually completely "lose" small windows. You end up having to forage around in the dead space blindly alt+clicking/dragging, hoping you can grab it and bring it back into view - what a pain! 
Comment 8 Felix Möller 2009-11-23 16:53:27 UTC
I have been annoyed by this for quiet some time.
Comment 9 Michal Zatloukal 2009-11-28 08:43:24 UTC
Let me also add a *complain* here. Using a widescreen monitor, having the panel on the side (right edge of B in my case) seems natural, but having to hunt for it because the cursor won't stop at the desktop edge makes the arrangement a PITA.

+==============+
|              |
|       A      |
|              |
|              |
+==========+===+
|          |
|    B     |
|          |
+==========+

BTW, you can bring windows out of the invisible area by triggering the window menu (Alt+F3 in KDE), selecting 'Move' and holding down the appropriate cursor key on the keyboard.
Comment 10 Felix Leif Keppmann 2009-12-05 01:49:59 UTC
I would like to complain about this ghost area too. Would be nice if the borders you can see are the real borders for mouse/windows too.

thx
Comment 11 Josef Kufner 2010-01-10 04:49:09 UTC
*complain*

Also, If you move mouse from A to C, it should appear in bottom left corner of B.

But maybe it would be nice, if it will appear at proportionaly same height at second screen. For example, A is 800px height, B is 300px height. If mouse is 400px from top of A whem moved from A to B or C, it should apear 300px from top of B (50% -> 50%). Same idea should work when moving up and down.

It could behave wierd while draging something, so if any button is down, this nicer behaviour should be disabled (?).
Comment 12 Calum 2010-02-27 16:37:45 UTC
*complain*

My setup is the same as OP with resolutions 1280x1024 & 1600x1200, so a 1280x200xpx chunk is mouse losing territory.


As others have described:

- losing icons in dead area
- losing windows in dead area
- mouse does not stop at edge when expected


I have no technical knowledge of the exact problem but if the desktop manager can control full-screening of windows why can't the mouse area be bounded like this too. I find it astonishing that such a basic multi monitor bug has not been resolved for three years.
From a lot of posts I have read it seem that users are resigned to the fact this bug exists but that does not equal them not wanting it fixed.
Comment 13 Flávio Etrusco 2010-02-27 17:03:35 UTC
Calum: I can only confirm the mouse problem, which is a bit annoying but you get used to it.
The other two is probably related to your window and desktop managers, and I certainly haven't seem anything like that in GNOME, metacity or compiz. Actually I don't remember having this problem with any somewhat current window or desktop manager: LXDE with openbox, icewm, KDE...
Comment 14 Calum 2010-02-27 17:51:13 UTC
I am using Ubuntu Karmic with Gnome, compiz and nVidia drivers.

I forgot to mention that my current dual monitor Linux setup is a compromise. I used to use Windows XP where the monitor heights were matched like this: 

              +=============+
   +==========+             |
   |          |             |
   |    B     |      A      |
   |          |             |
   +==========+             |
              +=============+

However when I changed to Ubuntu, I could not keep the same setup because icons and titlebars kept being hidden in the dead area at the top.

My desktop icons all appear on the far left screen, so if there are more than 8 vertically then several will be hidden in the dead area (depending on nautilus icon size). It is also very easy to drag an icon into the area.

I should clarify that the window manager does generally prevent windows disappearing in the dead area but it is still possible under certain circumstances. An obvious one is resizing from top of a window into the dead area thus making it vanish.


Comment 15 andruk 2010-04-25 14:51:35 UTC
*complain*

I would figure it would be obvious why this is a bad thing, and so I have not complained until now.  This is extremely annoying.  For all of the features ripped out of Metacity, it still seems to suck.  But I'll go grumble to the Gnome bugzilla instead (not that I expect them to do anything).  Keep up the good work X devs!
Comment 16 Wolfram 2010-04-25 19:12:02 UTC
*complain*

This issue is very annoying. So, you can see my complaints in xorg mail list: http://lists.freedesktop.org/archives/xorg/2010-April/050008.html

Also I've found the following topic about this issue: http://newyork.ubuntuforums.org/showthread.php?t=772087

Also you can check big topic on launchpad: https://bugs.launchpad.net/ubuntu/+source/libxrandr/+bug/373367
Comment 17 Federico Mena-Quintero 2010-04-26 12:18:02 UTC
This is the sanest message in those old threads:
http://lists.freedesktop.org/archives/xorg/2007-April/023047.html

Summary:  keep track of a motion vector for the mouse, and use a timeout/falloff to cancel the motion vector gradually.

Nothing in this needs to be configurable or client-side.  Get the behavior right and forget about it.
Comment 18 Federico Mena-Quintero 2010-04-26 12:21:20 UTC
Note to self - look for where WarpPointer gets handled; this should get us into the code for handling the mouse position in general.
Comment 19 Wolfram 2010-04-29 05:49:45 UTC
Re: Federico Mena-Quintero 2010-04-26 12:18:02 PDT 

Yeah, it's solution, but I think that it's still dirty hack/crutch. 
What about software mouse positioning at least? Does this method help in this case?
Comment 20 cpt.gosu 2010-04-29 06:05:01 UTC
*complain*
I'm using a laptop too, so I find this bug annoying.
Comment 21 pilat 2010-04-29 06:10:41 UTC
*complain*
Comment 22 Mike Burns 2010-04-29 06:20:38 UTC
It might be worth noting here that the two ways I notice this: new files appear in Nautilus below the visible part of my screen, and holding shift while moving a window snaps it to below the visible part of my screen.
Comment 23 Val 2010-04-29 08:03:43 UTC
Hello, any updates regarding this bug?

That's so annoying(((
Comment 24 candle 2010-04-29 10:16:00 UTC
*complain*

This drives me nuts too. This is very annoying to loose windows in large invisible area while drugging windows over monitors.
Comment 25 Julien Cristau 2010-04-29 10:22:32 UTC
> --- Comment #24 from candle <vsminkov+freedesktop@gmail.com> 2010-04-29 10:16:00 PDT ---
> *complain*
> 
if you have nothing useful to contribute, then just stay away, TIA.
Comment 26 candle 2010-04-29 10:49:39 UTC
(In reply to comment #25)
> > --- Comment #24 from candle <vsminkov+freedesktop@gmail.com> 2010-04-29 10:16:00 PDT ---
> > *complain*
> > 
> if you have nothing useful to contribute, then just stay away, TIA.

I'm really appreciated for huge work made by dev team. And I'm thinking that even my comments can change something. I just don't want that problem to be ignored.

>From http://lists.freedesktop.org/archives/xorg/2007-April/023004.html :
>"I don't think I've seen many user complaints from that."

I though each voice is worth... Sorry if I'm getting under the skin for anybody here
Comment 27 Wolfram 2010-05-02 02:50:04 UTC
The best behavior I've ever seen was with two displays configured as independent X displays: mouse cursor jumps into screen 1 when I'm trying to move it to invisible area from screen 2 and vise versa.

Maybe this behavior should be implemented for virtual desktop case?
It will be significantly better than windows/mac implementations.
Comment 28 Scumie 2010-06-29 16:13:48 UTC
(In reply to comment #27)
> The best behavior I've ever seen was with two displays configured as
> independent X displays: mouse cursor jumps into screen 1 when I'm trying to
> move it to invisible area from screen 2 and vise versa.
> 
> Maybe this behavior should be implemented for virtual desktop case?
> It will be significantly better than windows/mac implementations.

This behavior would be far annoying for particular scenarios as follows:
Consider using a paint or photo manipulation application on monitor 2. If you click and drag for example to paint an area, then reach the border which is very common while doing drag movements. The Cursor would just jump to Screen 1 at a very different coordinates, and in your paint application you would just see a vertical line at best, or just to unconnected dots. This would not work for the majority of users. Another example of annoying behavior would be dragging a window, where part of the window which just hasn't been moved yet to screen 1, would just seem to jump from one place to another.

Solution is just to prevent the cursor to enter the invisible area.
Comment 29 gdi2k@gmx.net 2010-06-29 20:04:28 UTC
I agree, I see nothing wrong with the Windows and Mac implementations. Making the cursor jump when moving from screen to screen would confuse. Simply don't let the cursor go where there is no screen space.
Comment 30 Michal Zatloukal 2010-06-30 00:57:50 UTC
(In reply to comment #29)
> I agree, I see nothing wrong with the Windows and Mac implementations. Making
> the cursor jump when moving from screen to screen would confuse. Simply don't
> let the cursor go where there is no screen space.

*sigh* The problem with Windows (and probably Mac) implementations is that they don't support discontiguous CRTC layouts AFAICT - when the desktops CRTCs have non-visible space in between them. I'm not sure there are any games for linux that would support/benefit from multi-monitor, but shelving this use case when AMD just recently went through great pains to implement it in Catalyst for their EyeFinity stuff just seems shortsighted. (the Catalyst driver can be configured to "leave out" a stripe between the CRTCs that corresponds to the monitor bezels - that way, applications which treat the setup as one giant display would avoid artifacts and the bezels would appear to actually "cover" the area instead of just dividing it) I'm thinking one could probably hack this by using panning mode and disabling the viewport movement, but you'd also have to tell the window manager not to use the whole area and use only the viewport instead (Quite an ugly hack IMO, but what do I know).
Comment 31 Wolfram 2010-06-30 05:23:08 UTC
So, maybe two different modes should be implemented? One with cursor jumps as I proposed (it will be suitable for noncontiguous layouts) and one with windows-like behavior. Preferred mode may be selected via xorg.conf and the second mode should be auto-disabled if noncontiguous layout is activated (maybe with warning printed into log).
Comment 32 Peter D. 2010-08-07 22:48:21 UTC
Just my two cents worth...  

Bezel spanning seems like an interesting idea, but it is sufficiently different that it should be handled differently.  Perhaps allow defining bezel area(s), defaulting to zero but configurable to the whole virtual desktop.  Perhaps treat a bezel area as a "null monitor".  Only allow the pointer to enter areas covered by at least one monitor or bezel.  That way on a properly configured system there would never be any "real" discontinuities.  I guess that that is an argument for letting the bezel area default to the virtual desktop.  When it is mis-configured make the pointer jump to the next real monitor.  

In most circumstances it would still be undesirable to have the pointer hidden by a bezel.  When the pointer is hidden, mark ALL real screens with a half pointer at the point nearest the virtual pointer.  (Or something that indicates, "it went over there".)  That way you would have some hope of finding the dam thing.  Have a configuration option to let it drift to the nearest real screen.  

Only experts and fools deliberately configure discontinuous screens.  Print a warning to the log and let the users decide which category they belong to.  

Anyone editing an image that spans multiple discontinuous monitors is either really expert or really optimistic.  For a start, they can't see what they are doing.
Comment 33 Federico Mena-Quintero 2010-12-09 12:39:28 UTC
http://lists.x.org/archives/xorg-devel/2010-November/015495.html has a tentative patch for this.
Comment 34 Skippy 2011-01-21 05:09:46 UTC
Probably related bugs or duplicates : bug 12562, bug 15253, bug 28893 & bug 32731.

Also, *complain*.  Just changed the setup, and my (few and useless) desktop icons have disappeared in the Bermud Rectangle.  This can be quite confusing for the lambda user.
Comment 35 Michal Zatloukal 2011-01-21 06:11:10 UTC
(In reply to comment #34)
> Also, *complain*.  Just changed the setup, and my (few and useless) desktop
> icons have disappeared in the Bermud Rectangle.  This can be quite confusing
> for the lambda user.

X has nothing to do with this IIRC. Icons and desktop layout is the DE/WM's responsibility - file a bug there.
Comment 36 Skippy 2011-01-21 07:01:42 UTC
(In reply to comment #35)
> (In reply to comment #34)
> > Also, *complain*.  Just changed the setup, and my (few and useless) desktop
> > icons have disappeared in the Bermud Rectangle.  This can be quite confusing
> > for the lambda user.
> 
> X has nothing to do with this IIRC. Icons and desktop layout is the DE/WM's
> responsibility - file a bug there.

No, this is a side effect of this bug.  As long as the virtual area is accessible, there is no reason for the DE/WM not to authorize icons or windows to move in the virtual area.  If this behaviour persists once the present bug is fixed, *then* I'll file a bug for that.
Comment 37 Michal Zatloukal 2011-01-21 07:12:50 UTC
(In reply to comment #36)
> No, this is a side effect of this bug.  As long as the virtual area is
> accessible, there is no reason for the DE/WM not to authorize icons or windows
> to move in the virtual area.  If this behaviour persists once the present bug
> is fixed, *then* I'll file a bug for that.

Window/icon coordinates are outside of X. I can move a window/icon OUTSIDE of the accessible area as long as the WM allows me to. It's the DE's responsibility to check which areas of the X screen are actually displayed on (any) monitor and place the icons/windows accordingly.
Comment 38 Calum 2011-01-21 15:39:54 UTC
(In reply to comment #37)
> (In reply to comment #36)
> > No, this is a side effect of this bug.  As long as the virtual area is
> > accessible, there is no reason for the DE/WM not to authorize icons or windows
> > to move in the virtual area.  If this behaviour persists once the present bug
> > is fixed, *then* I'll file a bug for that.
> 
> Window/icon coordinates are outside of X. I can move a window/icon OUTSIDE of
> the accessible area as long as the WM allows me to. It's the DE's
> responsibility to check which areas of the X screen are actually displayed on
> (any) monitor and place the icons/windows accordingly.

What happens when the mouse pointer issue is fixed and I find icons end up in this dead area? 
At the moment I can rescue them by drawing a selection box around a visible icon and those icons off the screen. Then, using the visible icon, I drag this group of icons until I can see them all on the desktop.

I thought I would add a link to the Ubuntu forums where I have just made a post with the other relevant multi-monitor bugs in case it is of help to anyone. 
http://ubuntuforums.org/showpost.php?p=10384602&postcount=17
Comment 39 Felix Möller 2011-04-04 03:43:38 UTC
I recently read somewhere this issue has been worked on. Sadly I cannot find the source anymore. Has somebody else read it or knows more?
Comment 40 Sean Flanigan 2011-04-06 17:41:21 UTC
Launchpad bug 389519 has some workarounds, including xcursorclamp: http://sourceforge.net/projects/xcursorclamp/
Comment 41 Vít Ondruch 2011-04-06 21:21:43 UTC
This seems to be fixed in Gnome 3. See latest updates of Fedora 15
Comment 42 Bob Ham 2011-04-07 04:31:46 UTC
(In reply to comment #41)
> This seems to be fixed in Gnome 3. See latest updates of Fedora 15

This is an X bug, not a GNOME bug.
Comment 43 Jeremy Nickurak 2011-06-20 14:47:02 UTC
As I understand it, Gnome 3 is relying on the pointer barrier work in http://cgit.freedesktop.org/xorg/xserver/commit/?id=d45f5b2493bc0a2882bf972849b5c9c50cd533ca to support their correction for this.
Comment 44 hgkamath 2011-06-26 21:52:57 UTC
Is anyone else seeing this,
https://bugzilla.redhat.com/show_bug.cgi?id=710191
Is the resolution of this issue, anyway related to this.

fedora-15 2.6.38.8-32
xorg-x11-server-Xorg-1.10.2-1.fc15.x86_64

Upon using randr to create a screen larger than the monitor, 
the mouse pointer is stuck in the original area.

try 
  xrandr --fb 1600x1200 --output LVDS --mode 1280x800 --panning 1600x1200
and
  xrandr --fb 1280x800  --output LVDS --mode 1280x800 --panning 1280x800
to restore.
Comment 45 Timo Aaltonen 2011-06-28 06:13:17 UTC
This is fixed in xserver master, and a slightly earlier revision in Fedora 15.
Comment 46 hgkamath 2011-06-28 21:14:32 UTC
(In reply to comment #45)

Good to hear, will report if and when fix trickles downstream.
Comment 47 Jeremy Huddleston Sequoia 2011-10-08 13:10:56 UTC
*** Bug 12562 has been marked as a duplicate of this bug. ***
Comment 48 Jeremy Huddleston Sequoia 2011-10-08 13:24:53 UTC
*** Bug 28893 has been marked as a duplicate of this bug. ***

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.