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
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*
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.
*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)
*** Bug 22750 has been marked as a duplicate of this bug. ***
*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 (?).
*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.
*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 <vsminkov+freedesktop@gmail.com> 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 <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
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.
(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.
http://lists.x.org/archives/xorg-devel/2010-November/015495.html has a tentative patch for this.
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
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.
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.
This is fixed in xserver master, and a slightly earlier revision in Fedora 15.
(In reply to comment #45) Good to hear, will report if and when fix trickles downstream.
*** Bug 12562 has been marked as a duplicate of this bug. ***
*** 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.