Button 2 position is reported wrong after fast user switching

[mthorn@…]

Seen on a system running MacOS X 10.5.8. XQuartz 2.5.0 (xorg-server 1.7.6). Mouse is a Logitech bluetooth mouse with a middle scroll button that is reported as button 2 when pressed, and buttons 4 and 5 when scrolled in the two different directions.

1. Login as user A
2. Start an xterm
3. Use fast user switching to log in as user B
4. Start an xterm as user B

Running "xinput test pointer" shows that the position of button 2 is reported incorrectly when clicked, while the positions of buttons 1 and 3 are still reported correctly when clicked. xev shows that clicking button B outside of the black boundary will be reported as a LeaveNotify event or no event at all.

% xinput test pointer
button press   1 a[0]=666 a[1]=187 
button release 1 a[0]=666 a[1]=187 
button press   2 a[0]=625 a[1]=0 
button release 2 a[0]=625 a[1]=0 
button press   3 a[0]=666 a[1]=187 
button release 3 a[0]=666 a[1]=187 
button press   1 a[0]=666 a[1]=187 
button release 1 a[0]=666 a[1]=187 
button press   2 a[0]=625 a[1]=0 
button release 2 a[0]=625 a[1]=0 
button press   3 a[0]=666 a[1]=187 
button release 3 a[0]=666 a[1]=187 
button press   1 a[0]=666 a[1]=187 
button release 1 a[0]=666 a[1]=187 
button press   2 a[0]=625 a[1]=0 
button release 2 a[0]=625 a[1]=0 
button press   3 a[0]=666 a[1]=187 
button release 3 a[0]=666 a[1]=187 
button press   1 a[0]=666 a[1]=187 
motion a[0]=670 a[1]=188 
motion a[0]=671 a[1]=188 
button release 1 a[0]=671 a[1]=188 
button press   2 a[0]=635 a[1]=0 
button release 2 a[0]=635 a[1]=0 
button press   3 a[0]=671 a[1]=188 
button release 3 a[0]=671 a[1]=188 

[mthorn@…]

Sorry "xev shows that clicking button B" should read "xev shows that clicking button 2"

[otte@…]

Replying to mthorn@…:

I mentioned this too in an email I sent to the mailing list in December ( http://lists.macosforge.org/pipermail/xquartz-dev/2009-December/002705.html), but never got around to adding a bug report. I am getting this problem with snow leopard.

Only the middle click is affected, not the left and right clicks. As far as I can tell, the deltaXY values for middle clicks become erroneous during fast user switching. I get around this problem when compiling the macports server by adding an exception for middle clicks in X11Application.m, as was done for tablets. Please see the attached file xorg-server-middle_click.patch.

Since I use the macports X11 servers with this patch, I don't know if the latest operating system update has fixed this problem yet.

[jeremyhu@…]

I tested this on quake2 (which was an obvious example that required the other code path), and it seems fine.

[jeremyhu@…]

< rdar://problem/7989666>

[jeremyhu@…]

This is in my git tree and will be in 2.5.1_rc1