Bug 88506 - dragged window follows mouse but on wrong screen (dual-head non-xinerama)
Summary: dragged window follows mouse but on wrong screen (dual-head non-xinerama)
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: multi-screen (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal with 2 votes (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 80586 120672 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-08-31 09:48 UTC by Luke
Modified: 2006-11-28 17:38 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke 2004-08-31 09:48:38 UTC
Version:            (using KDE KDE 3.3.0)
Installed from:    Gentoo Packages
Compiler:          gcc-3.4.1 
OS:                Linux

This bug applies to using dual screens, but without using Xinerama (so they are not combined into a single desktop).

When dragging a window, if the mouse is moved to another screen, the window stays on the same screen (this is unfortunate, but is probably unavoidable as the screens have different DISPLAY settings, eg DISPLAY=:0.0 vs DISPLAY=:0.1).

The problem is that the window still behaves as if it is being dragged; it moves around on its original screen as if the mouse were still on that screen.

Steps to reproduce (assuming two screens, "left-screen" and "right-screen":
(1) open a window on left-screen
(2) drag the window beyond the right edge of left-screen

Results:
- the mouse will appear on the left edge of right-screen
- the window will jump to the left edge of left-screen (matching the position of the mouse on right-screen)

Expected Results:
- the window will be dragged to right-screen (ideal, but perhaps impossible)
- alternatively, the window should stop being dragged when the mouse leaves left-screen.
Comment 1 Luke 2004-09-16 01:46:45 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.
Comment 2 Luke 2004-09-16 03:17:43 UTC
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
Comment 3 Luke 2004-12-30 00:37:06 UTC
oops is this a dupe of bug 80586? (though that bug is against "kde" rather than "kwin")
Comment 4 Lubos Lunak 2004-12-30 00:50:30 UTC
*** Bug 80586 has been marked as a duplicate of this bug. ***
Comment 5 Binggeli 2005-10-10 09:44:26 UTC
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?
Comment 6 Martin Nicholas 2005-10-22 13:45:02 UTC
Dragging icons window to window works fine BTW.
Comment 7 Lubos Lunak 2006-02-20 19:13:25 UTC
*** Bug 120672 has been marked as a duplicate of this bug. ***
Comment 8 Soren Sandmann 2006-11-21 06:53:20 UTC
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.
Comment 9 Lubos Lunak 2006-11-28 15:13:25 UTC
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.
Comment 10 Lubos Lunak 2006-11-28 15:14:39 UTC
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;
Comment 11 Soren Sandmann 2006-11-28 17:13:09 UTC
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. 
Comment 12 Lubos Lunak 2006-11-28 17:38:01 UTC
It's not the root window but it has the same geometry, so it should be the same.