Summary: | dragged window follows mouse but on wrong screen (dual-head non-xinerama) | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Luke <luke> |
Component: | multi-screen | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | christoph.gutmann, inform, john, sandmann |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Gentoo Packages | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Luke
2004-08-31 09:48:38 UTC
There are also analagous problems when resizing a window with the mouse, and the mouse moves to another display: the window resize operation behaves as if the mouse was at the matching position on the first display. This bug can be easily reproduced if you have a laptop with a half-decent video card and a spare monitor. In case someone wants to try confirming this bug but isn't sure how to get dual head working, I'll add a brief note here on how I set it up. My laptop has a radeon 9000 card. The following should work for most recent ATI cards. Something similar should work with nvidia cards. In your xorg.cfg (/ XF86Config), you need to add a second "Monitor" section, "Device" section, and "Screen" section. Try something like the following (a relevant snippet from xorg.cfg): Section "Monitor" Identifier "Monitor1" HorizSync 30-100 VertRefresh 20-100 # these will be ignored if your monitor supports DPMS Option "DPMS" EndSection Section "Monitor" Identifier "Monitor2" HorizSync 30-100 VertRefresh 20-100 # these will be ignored if your monitor supports DPMS Option "DPMS" EndSection Section "Device" Identifier "Radeon connector 1" Driver "radeon" # don't use "fglrx", it doesn't work Screen 0 EndSection Section "Device" Identifier "Radeon connector 2" Driver "radeon" # don't use "fglrx", it doesn't work Screen 1 EndSection Section "Screen" Identifier "Radeon screen 1" Device "Radeon connector 1" Monitor "Monitor1" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1400x1050" EndSubsection EndSection "Screen" Section "Screen" Identifier "Radeon screen 2" Device "Radeon connector 2" Monitor "Monitor2" DefaultDepth 24 Subsection "Display" Depth 24 Modes "1024x768" EndSubsection EndSection "Screen" Section "ServerLayout" Identifier "Server Layout" Screen "Radeon screen 1" Screen "Radeon screen 2" RightOf "Radeon screen 1" # put InputDevice lines here to reference mouse and keyboard sections EndSection oops is this a dupe of bug 80586? (though that bug is against "kde" rather than "kwin") *** Bug 80586 has been marked as a duplicate of this bug. *** This seems to be an elder report: to have this fixed would be very valuable for me. Does anyone know wether this will be fixed? Dragging icons window to window works fine BTW. *** Bug 120672 has been marked as a duplicate of this bug. *** FWIW, what metacity does is just confining the mouse pointer to the screen in question. That way the mouse pointer can't cross between screens, and the problem doesn't happen. That's a good idea, thanks. It however doesn't change anything about the fact the multihead support in KDE in unmaintained and users should use Xinerama. SVN commit 608812 by lunakl: Configure mouse to the screen when doing move/resize. BUG: 88506 M +1 -1 geometry.cpp --- branches/KDE/3.5/kdebase/kwin/geometry.cpp #608811:608812 @@ -2258,7 +2258,7 @@ XMapRaised( qt_xdisplay(), move_resize_grab_window ); if( XGrabPointer( qt_xdisplay(), move_resize_grab_window, False, ButtonPressMask | ButtonReleaseMask | PointerMotionMask | EnterWindowMask | LeaveWindowMask, - GrabModeAsync, GrabModeAsync, None, cursor.handle(), qt_x_time ) == Success ) + GrabModeAsync, GrabModeAsync, move_resize_grab_window, cursor.handle(), qt_x_time ) == Success ) has_grab = true; if( XGrabKeyboard( qt_xdisplay(), frameId(), False, GrabModeAsync, GrabModeAsync, qt_x_time ) == Success ) has_grab = true; Is it guaranteed that the move_resize_grab_window is always the root window of the client in question? I would have thought that workspace()->rootWin() was a better bet. It's not the root window but it has the same geometry, so it should be the same. |