[Needs 1.11]Cursor can move off-screen when dual-monitors do not form rectangular area

Bug #389519 reported by Craig Estep on 2009-06-19
206
This bug affects 58 people
Affects Status Importance Assigned to Milestone
xf86-video-intel
Fix Released
Medium
xorg-server (Ubuntu)
High
Unassigned
xorg-server (openSUSE)
Unknown
Unknown

Bug Description

Binary package hint: xorg

lsb_release -rd
Description: Ubuntu karmic (development branch)
Release: 9.10

xorg:
  Installed: 1:7.4~5ubuntu21
  Candidate: 1:7.4~5ubuntu21
  Version table:
 *** 1:7.4~5ubuntu21 0
        500 http://us.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

Basically, when I use two monitors with different sizes (1280x800 and 1680x1050), X creates a rectangular bounding box for the cursor, so in effect it can move offscreen. I assumed that it would stop the cursor from leaving any part of either monitor unless it was moving to the other display.

lspci -nn | grep VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c)

ProblemType: Bug
Architecture: i386
Date: Fri Jun 19 10:39:59 2009
DistroRelease: Ubuntu 9.10
MachineType: TOSHIBA Satellite A205
Package: xorg 1:7.4~5ubuntu21
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.30-8-generic root=UUID=942307cb-160e-41ff-a4ee-0e8dd8393170 ro quiet splash
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.30-8.9-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4~5ubuntu21
 libgl1-mesa-glx 7.4.1-1ubuntu2
 libdrm2 2.4.11-0ubuntu1
 xserver-xorg-video-intel 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu2
 xserver-xorg-video-ati 1:6.12.2-2ubuntu1
SourcePackage: xorg
Uname: Linux 2.6.30-8-generic i686
dmi.bios.date: 03/10/2008
dmi.bios.vendor: TOSHIBA
dmi.bios.version: V2.20
dmi.board.name: ISKAA
dmi.board.vendor: TOSHIBA
dmi.board.version: 1.00
dmi.chassis.asset.tag: *
dmi.chassis.type: 10
dmi.chassis.vendor: TOSHIBA
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnTOSHIBA:bvrV2.20:bd03/10/2008:svnTOSHIBA:pnSatelliteA205:pvrPSAE3U-07Y023:rvnTOSHIBA:rnISKAA:rvr1.00:cvnTOSHIBA:ct10:cvrN/A:
dmi.product.name: Satellite A205
dmi.product.version: PSAE3U-07Y023
dmi.sys.vendor: TOSHIBA
fglrx: Not loaded
system:
 distro: Ubuntu
 architecture: i686kernel: 2.6.30-8-generic

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 :-)

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*

Binary package hint: xorg

lsb_release -rd
Description: Ubuntu karmic (development branch)
Release: 9.10

xorg:
  Installed: 1:7.4~5ubuntu21
  Candidate: 1:7.4~5ubuntu21
  Version table:
 *** 1:7.4~5ubuntu21 0
        500 http://us.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

Basically, when I use two monitors with different sizes (1280x800 and 1680x1050), X creates a rectangular bounding box for the cursor, so in effect it can move offscreen. I assumed that it would stop the cursor from leaving any part of either monitor unless it was moving to the other display.

lspci -nn | grep VGA
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c)

ProblemType: Bug
Architecture: i386
Date: Fri Jun 19 10:39:59 2009
DistroRelease: Ubuntu 9.10
MachineType: TOSHIBA Satellite A205
Package: xorg 1:7.4~5ubuntu21
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.30-8-generic root=UUID=942307cb-160e-41ff-a4ee-0e8dd8393170 ro quiet splash
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.30-8.9-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4~5ubuntu21
 libgl1-mesa-glx 7.4.1-1ubuntu2
 libdrm2 2.4.11-0ubuntu1
 xserver-xorg-video-intel 2:2.7.99.1+git20090602.ec2fde7c-0ubuntu2
 xserver-xorg-video-ati 1:6.12.2-2ubuntu1
SourcePackage: xorg
Uname: Linux 2.6.30-8-generic i686
dmi.bios.date: 03/10/2008
dmi.bios.vendor: TOSHIBA
dmi.bios.version: V2.20
dmi.board.name: ISKAA
dmi.board.vendor: TOSHIBA
dmi.board.version: 1.00
dmi.chassis.asset.tag: *
dmi.chassis.type: 10
dmi.chassis.vendor: TOSHIBA
dmi.chassis.version: N/A
dmi.modalias: dmi:bvnTOSHIBA:bvrV2.20:bd03/10/2008:svnTOSHIBA:pnSatelliteA205:pvrPSAE3U-07Y023:rvnTOSHIBA:rnISKAA:rvr1.00:cvnTOSHIBA:ct10:cvrN/A:
dmi.product.name: Satellite A205
dmi.product.version: PSAE3U-07Y023
dmi.sys.vendor: TOSHIBA
fglrx: Not loaded
system:
 distro: Ubuntu
 architecture: i686kernel: 2.6.30-8-generic

Craig Estep (craigy) wrote :

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.

Bryce Harrington (bryce) on 2009-06-26
affects: xorg (Ubuntu) → xserver-xorg-video-intel (Ubuntu)
summary: - [karmic] Cursor can move off-screen when dual-monitors do not form
- rectangular area
+ [i965gm] [karmic] Cursor can move off-screen when dual-monitors do not
+ form rectangular area
Bryce Harrington (bryce) on 2009-06-26
Changed in xserver-xorg-video-intel (Ubuntu):
status: New → Confirmed

*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.

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)

Geir Ove Myhr (gomyhr) on 2009-07-05
tags: added: 965gm jaunty mouse
Bryce Harrington (bryce) on 2009-07-10
tags: added: karmic
Changed in xserver-xorg-video-intel (Ubuntu):
status: Confirmed → Triaged
Rolf Leggewie (r0lf) on 2009-07-12
summary: - [i965gm] [karmic] Cursor can move off-screen when dual-monitors do not
- form rectangular area
+ Cursor can move off-screen when dual-monitors do not form rectangular
+ area

This is expected behaviour in xorg and not only since Karmic. What do you expect the cursor to do when moving in and out of that area not covered by either of the monitors? One camp of users wants it to move around freely while the other camp wants the cursor to strictly stay within the visible screens. I'm from the second camp, you seem to be from the first. I think this may even be configurable. I looked around quite a bit (I was sure to have a bug report to the opposite effect some time ago), yet found nothing.

I think this report should be closed with status invalid.

I'm from the second camp too! It is quite annoying to me when my cursor gets lost off-screen. However, as it currently stands, the cursor CAN move "in and out of the area not covered by either monitor". I'm sorry if I wasn't clear, and I apologize for implying that this was introduced in karmic. I am still learning.

Are you saying that the expected behavior is that the cursor IS kept inside of both screens? If so, I think my bug is valid. Please correct me if I am wrong. Thanks

Bryce Harrington (bryce) on 2009-07-13
summary: - Cursor can move off-screen when dual-monitors do not form rectangular
- area
+ [i965gm] Cursor can move off-screen when dual-monitors do not form
+ rectangular area

Hi Craig,

I've forwarded your bug upstream to https://bugs.freedesktop.org/show_bug.cgi?id=22750 - please subscribe to this bug in case upstream needs further information or wishes you to test something. Thanks ahead of time!

Changed in xserver-xorg-video-intel:
status: Unknown → Confirmed

*** Bug 22750 has been marked as a duplicate of this bug. ***

Bryce Harrington (bryce) on 2009-07-16
Changed in xserver-xorg-video-intel:
status: Confirmed → Unknown
Changed in xserver-xorg-video-intel:
status: Unknown → Confirmed
Bryce Harrington (bryce) on 2009-07-30
Changed in xserver-xorg-video-intel (Ubuntu):
importance: Undecided → Wishlist
importance: Wishlist → High

*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!

I have been annoyed by this for quiet some time.

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.

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

*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 (?).

Bryce Harrington (bryce) on 2010-02-27
tags: added: dual-head

*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.

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...

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.

Bryce Harrington (bryce) on 2010-03-02
summary: - [i965gm] Cursor can move off-screen when dual-monitors do not form
- rectangular area
+ [i965] [i965gm] Cursor can move off-screen when dual-monitors do not
+ form rectangular area
Bryce Harrington (bryce) on 2010-03-02
summary: - [i965] [i965gm] Cursor can move off-screen when dual-monitors do not
- form rectangular area
+ [i965gm] Cursor can move off-screen when dual-monitors do not form
+ rectangular area

*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!

*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

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.

Note to self - look for where WarpPointer gets handled; this should get us into the code for handling the mouse position in general.

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?

*complain*
I'm using a laptop too, so I find this bug annoying.

*complain*

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.

Hello, any updates regarding this bug?

That's so annoying(((

*complain*

This drives me nuts too. This is very annoying to loose windows in large invisible area while drugging windows over monitors.

> --- Comment #24 from candle <email address hidden> 2010-04-29 10:16:00 PDT ---
> *complain*
>
if you have nothing useful to contribute, then just stay away, TIA.

(In reply to comment #25)
> > --- Comment #24 from candle <email address hidden> 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

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.

Bryce Harrington (bryce) on 2010-05-21
tags: added: hardy

(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.

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.

(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).

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).

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.

Moving to xorg-server, where this problem actually lies.

Note that this is somewhat of a thorny problem requiring the development of a new policy or mechanism for what should happen.

This could also be fixed by a GNOME client component working with the existing Monitors system.

affects: xserver-xorg-video-intel (Ubuntu) → xorg-server (Ubuntu)
summary: - [i965gm] Cursor can move off-screen when dual-monitors do not form
- rectangular area
+ Cursor can move off-screen when dual-monitors do not form rectangular
+ area
Changed in xserver-xorg-video-intel:
importance: Unknown → Medium
status: Confirmed → In Progress

Problem also occurs on my Toshiba Satellite U405, with Intel GMA X3100 graphics: mouse moving into the "dead space" above the top menu bar on the laptop monitor.

Is there any estimate how or when it might be resolved? I suspect it affects any person who uses dual monitors with a laptop, since generally the laptop screen height is not the same as a CRT or LCD display. It's hard for me to believe it's been discussed since March 2007 (per response #1) and still no patch ;-P

In almost all cases, I suspect the user will have two displays side-by-side that are different heights. It should be relatively simple to add a solution for this situation, taking care of 99% of the open cases. All that needs to be done is to prevent the mouse from entering the dead space (and respectively prevent windows from being moved there).

nZain (patrick-stalph) wrote :

If you're looking for a simple workaround for the mouse problem (which is not polling the mouse), I wrote a small tool to prevent the mouse from entering the void. This is not a patch, nor will it satisfy everyone. Refer to

https://bugs.launchpad.net/ubuntu/+source/libxrandr/+bug/373367/comments/10

This is just a workaround until this tricky topic gets handled upstream by implementing one or more policies.

one51 (one51s) wrote :

nZain, thanks a lot! Works perfectly, and I even have the same monitor dimensions, so even copy/paste of the sample "execute" line works for me. I'll put it in startup as I hardly ever transport this laptop.

Such a fix as you did would be SO easy to incorporate into X... but I suppose it will take another year...

You get +999,999 points for "creativity and helpfulness in the face of interminable open-source bugfix discussions about simple problems which could persuade otherwise reasonable people to return to W*ndoze." :-)

nZain (patrick-stalph) wrote :

Thanks for the flowers, but what "I did" is not a fix :) And I agree with the devs that the topic isn't solved easily. People have very different habbits and "in my/your oppinion"-weird layouts may be useful to others. However, I also agree with you that at least some options (that extend the current default behavior) could be implemented rather quickly. Anyways, this is open source and we love it. So don't expect something to be done quickly... or do it yourself and provide a patch ;-) I can't do it.

Rune Juhl Jacobsen (runejuhl) wrote :

nZain, thanks for the hack.

For other with this problem, a slightly improved version of nZains hack has been published by Alexey A. Kiritchun in https://bugs.launchpad.net/ubuntu/+source/libxrandr/+bug/373367/comments/30

Chris Halse Rogers (raof) wrote :

There's a patch by Adam Jackson on xorg-devel to constrain the cursor when all CRTCs are reachable which would resolve this bug. I've given it a review, but it was before the holidays and so may have been missed in all the absences.

I'll push this along.

Changed in xorg-server (Ubuntu):
assignee: nobody → Chris Halse Rogers (raof)

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.

(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.

(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.

(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.

(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

Changed in xserver-xorg-video-intel:
importance: Medium → Unknown
Changed in xserver-xorg-video-intel:
importance: Unknown → Medium
Jelle Geerts (jellegeerts) wrote :

Hi, I've created a program called `xcursorclamp' which works around this issue by automatically calculating which regions of the virtual screen are invisible and creating undecorated windows that cover these regions. Whenever the mouse cursor hits such a window, the program will clamp the cursor to the nearest visible region. It will adjust automatically when the invisible regions change as a result of the user changing the X monitor configuration while the program was running.

Of course xcursorclamp is free software (GPLv3+), see http://sourceforge.net/projects/xcursorclamp/

Chris Halse Rogers (raof) wrote :

Unassigning me; we're past Feature Freeze and the 1.10 release. This should land in Xserver 1.11, so should land in Natty+1.

Changed in xorg-server (Ubuntu):
assignee: Chris Halse Rogers (raof) → nobody
summary: - Cursor can move off-screen when dual-monitors do not form rectangular
- area
+ [Needs 1.11]Cursor can move off-screen when dual-monitors do not form
+ rectangular area
Ernest French (ernestfrench) wrote :

Great to hear! this bothered me too.
I'd like to point out another solution to dealing with multi-monitors that I think solves a lot of the problems:
I have two monitors connected by one corner (instead of an entire edge). I like it because it's still really easy to switch monitors, but you almost never do it by accident. (with an entire edge shared, accidentally crossing over and clicking something happens way too much). It would be great if this was supported. regards!

Marcus Sundman (sundman) wrote :

@Ernest, yes, that's how I, too, like it. It's extremely useful to have so much border estate. I used to have such a setup a decade ago when I was still using windows, but unfortunately haven't been able to use such a setup yet after switching to linux.

@Chris, where are the details of what exactly "should land in Xserver 1.11" regarding this issue?

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?

Launchpad bug 389519 has some workarounds, including xcursorclamp: http://sourceforge.net/projects/xcursorclamp/

This seems to be fixed in Gnome 3. See latest updates of Fedora 15

(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.

Yury V. Zaytsev (zyv) wrote :

1) I still don't get it whether it's a xorg, driver or DE problem, or all of the above. That is when your fix lands in Natty+1 would it automatically work for Gnome 2, XFCE and whatever, or only in those DEs that support it etc.?

2) In the meantime, is xcursorclamp packaged for Ubuntu?

Cas (calumlind) wrote :

I found that xcursorclamp did not work for me however an updated version of XCreateMouseVoid from Bug #373367 works perfectly for me.

To make it easier to find and manage I have pulled the code into my github repo: https://github.com/cas--/XCreateMouseVoid

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.

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.

Timo Aaltonen (tjaalton) wrote :

Oneiric has a backported patch for this, but something is still missing from making it operational.

Changed in xorg-server (Ubuntu):
status: Triaged → In Progress

This is fixed in xserver master, and a slightly earlier revision in Fedora 15.

Timo Aaltonen (tjaalton) wrote :

fixed in git.

Changed in xorg-server (Ubuntu):
status: In Progress → Fix Committed
Changed in xserver-xorg-video-intel:
status: In Progress → Fix Released

(In reply to comment #45)

Good to hear, will report if and when fix trickles downstream.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xorg-server - 2:1.10.2.902-1ubuntu1

---------------
xorg-server (2:1.10.2.902-1ubuntu1) oneiric; urgency=low

  * Merge from Debian unstable. (LP: #441653)
    - Update 500_xi2.1.patch to apply.
    - Drop patch 218_randr-check-rotated-virtual-size-limits-correctly.diff,
      fixed upstream.
  * Update the crtc confinement patch with one that should work, with
    further fixes from upstream. (LP: #389519)
  * Dropped a bunch of old Breaks from xserver-xorg-core.

xorg-server (2:1.10.2.902-1) unstable; urgency=low

  * New upstream release (1.10.3 rc2):
    - DIX: Set backgroundState correctly for root window (Closes: #632134).
  * Drop 20-workaround-36986.diff, fixed upstream.
  * Bump Standards-Version to 3.9.2 (no changes).

xorg-server (2:1.10.2-2) unstable; urgency=low

  * Bump libgl1-mesa-dri versioned Recommends to 7.10.2-4, to lower the
    odds of having a server built against multiarched mesa, installed
    along a pre-multiarch mesa. The Breaks in mesa packages take care of
    the other way round already.
  * And since the server's binNMU managed to migrate to testing way too
    early, add a Breaks against pre-multiarch libgl1-mesa-dri and
    libgl1-mesa-dri-experimental.
 -- Timo Aaltonen <email address hidden> Tue, 05 Jul 2011 16:22:23 +0300

Changed in xorg-server (Ubuntu):
status: Fix Committed → Fix Released

*** Bug 12562 has been marked as a duplicate of this bug. ***

*** Bug 28893 has been marked as a duplicate of this bug. ***

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.