Created attachment 27632 [details] Xorg.0.log Forwarding this bug from Ubuntu reporter Craig Estep: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/389519 [Problem] When two monitors of different resolutions are combined in extended desktop mode, there is a "dead area" where the mouse can move (and get lost). [Original Report] sb_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
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.
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.