Bug 22750

Created attachment 27633 [details]
CurrentDmesg.txt

Created attachment 27634 [details]
Xrandr.txt

Created attachment 27635 [details]
monitors.xml.txt

Created attachment 27636 [details]
xdpyinfo.txt

jbarnes says: this is expected as how xinerama works.

I've had *several* people ask me about this problem, so I'm reopening to ask if you could give it another thought or at least give a more detailed explanation as to *why* it is this way?

A common use case I get presented with is with presentations, where the laptop and projector are significantly different resolutions, and the mouse (and sometimes application windows) get lost in this dead area.

Keith/Jesse, could you explain?

The server allows the pointer to roam over the entire screen. If the monitors do not cover the entire screen, there will be areas of the screen hidden from view where the pointer can still go.

There's no way to fix this in the driver, it must be fixed in the server.

When doing the original RandR work, I tried several different pointer constraint plans but never found something that worked very well, so I gave up. It seems so easy, and yet once you start considering gaps between monitors, lots of 'obviously reasonable' plans start to fail.

The window manager should be aware of the dead space however, so a reasonable improvement might be to provide a window manager hotkey to move the mouse to the center of one of the active displays, or somehow "bounce" the mouse back into an active space if it gets lost.  Like Keith said though, this is a hard issue to solve generally, but a window manager hack could be configurable and handle the basic cases of side-by-side or top-and-bottom configurations.

*** This bug has been marked as a duplicate of bug 20334 ***

On Wed, Jul 15, 2009 at 09:59:22AM -0700, bugzilla-daemon@freedesktop.org wrote:
> The server allows the pointer to roam over the entire screen. If the monitors
> do not cover the entire screen, there will be areas of the screen hidden from
> view where the pointer can still go.
> 
> There's no way to fix this in the driver, it must be fixed in the server.
> 
> When doing the original RandR work, I tried several different pointer
> constraint plans but never found something that worked very well, so I gave up.
> It seems so easy, and yet once you start considering gaps between monitors,
> lots of 'obviously reasonable' plans start to fail.

The model that would seem most intuitive would be to ignore gaps and
warp to the near border of the next CRTC along: for instance, if you
have:

+------------------------------------------------------------+
|  +-------------------+---------------+                     |
|  |                   |               |                     |
|  |                  a|       2       |                     |
|  |         1         |  c           d|                     |
|  |                   +---------------+                     |
|  |                   |                                     |
|  |    f             b|             +-------------------+   |
|  +-------------------+             |e                  |   | |                                    |         3         |   |
|                                    |g                  |   |
|                                    |                   |   |
|                                    +-------------------+   |
+------------------------------------------------------------+

then:
  * moving right from a moves to 2
  * moving right from b moves to 3, moving down gets clipped away
  * moving down from c gets clipped away
  * moving down from d goes to 3, moving right gets clipped away
  * moving left from e goes to 1, moving up goes to 2
  * moving down from f gets clipped away
  * moving down from g gets clipped away

This would mean that if you moved 3 down and right such that it didn't
intersect along a non-diagonal line with either 1 or 2, it would be
impossible to move a cursor there, but I think 'don't do that' is a
reasonable answer for the meantime; either that or gravitate 'lost'
CRTCs towards otherwise-grouped ones for border calculation purposes.

Cheers,
Daniel

This seems like a good approach.  From discussions I've hard with users, this would solve their immediate issue with minimum confusion.

A situation that the above scheme solves nicely is if the user sets up dual head, and then reduces the resolution of the left screen, without altering the x,y positions of either screen.  I don't know if such a thing occurs much in practice but if so, it would suffer from the "lost cursor" problem, and so this approach would solve that.