Hi, As far as I can tell, the left and right clicks are fine. When the middle click problem appears, it only alleviates when both users log out (so that nobody is logged in on the console). I think this is just a recent problem, but I haven't used FUS enough to know when this problem might have first appeared. Should I create a bug ticket for this? Martin On Dec 30, 2009, at 11:54 PM, Jeremy Huddleston wrote:
Weird that it would be *just* middle clicks. Can you confirm that left and right clicks don't exhibit this behavior... also, if you move the mouse around after the FUS, I'm guessing it gets corrected, right?
Thanks, Jeremy
On Dec 30, 2009, at 15:28, Martin Otte wrote:
Hi,
On 2 different machines (both OSX 10.6.2) with recent X servers (1.7.3), I find that that the middle mouse click is broken when I login using fast user switching when another user is already logged in. "Fake" middle clicks work correctly.
The steps to reproduce this are: 1) Make sure that you are not logged in and that another user is. 2) Use fast user switching to log into your account while the previous user is still logged in. 3) Start the X server. Try copying and then pasting with the middle mouse button; it doesn't work for me.
After some debugging in darwinEvents.c, it looks like the reported x and y positions of the middle click are wrong and are different than for the left and right clicks. I can get the middle click to work in an xterm window if I first maximize the window to fit most of the screen. If I then middle click to paste with the mouse pointer near the middle of the xterm, the paste works because the erroneous x and y points are then probably still within the xterm window.
Further debugging shows that the problem occurs in X11Application.m, in the routine sendX11NSEvent, near line 1027:
} else { location.x = lastpt.x + [e deltaX]; location.y = lastpt.y - [e deltaY]; lastpt = [e locationInWindow]; }
After I login using fast user switching, the deltaX and deltaY values for middle clicks are erroneous. As a temporary fix, I noticed that in the block of code just above this, you added an exception for tablets where the reported deltas are bad; so I just added middle clicks to the exceptions:
diff -up hw/xquartz/X11Application.m.baddeltas hw/xquartz/X11Application.m --- hw/xquartz/X11Application.m.baddeltas 2009-12-30 15:05:54.000000000 -0500 +++ hw/xquartz/X11Application.m 2009-12-30 15:08:38.000000000 -0500 @@ -1015,12 +1015,13 @@ static inline int ensure_flag(int flags, location.x += frame.origin.x; location.y += frame.origin.y; lastpt = location; - } else if(isTabletEvent) { + } else if(isTabletEvent || [e type] == NSOtherMouseDown || [e type] == NSOtherMouseUp) { // NSEvents for tablets are not consistent wrt deltaXY between events, so we cannot rely on that // Thus tablets will be subject to the warp-pointer bug worked around by the delta, but tablets // are not normally used in cases where that bug would present itself, so this is a fair tradeoff // <rdar://problem/7111003> deltaX and deltaY are incorrect for NSMouseMoved, NSTabletPointEventSubtype // http://xquartz.macosforge.org/trac/ticket/288 + // The deltaXY for middle click events also appear erroneous during fast user switching location = [e locationInWindow]; lastpt = location; } else {
I'll assume that there shouldn't be a problem with the warp-pointer bug for just mouse click events.
Please see if you can reproduce this bug and if this patch may be worthwhile for fixing it.
Martin
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev