When switching from another virtual terminal back to the X.org VT, the mouse driver (xf86-input-mouse >=1.2.2) generates spurious ButtonRelease events for all buttons, causing applications which rely on ButtonRelease indicating a change of state to misbehave.

The offending code is in xf86-input-mouse/src/mouse.c:FlushButtons(), called from a DEVICE_ON event to MouseProc().  This routine blindly sends button-up for all buttons events via xf86PostButtonEvent(), with the comment that "If no button down is pending xf86PostButtonEvent() will discard them. So we are on the safe side."  However (in xorg-xserver >=1.4), neither hw/xfree86/common/xf86Xinput.c:xf86PostButtonEvent() nor its subroutine
dix/getevents.c:GetPointerEvents() seem to make any such check, and the artificial ButtonRelease events are passed on to any X clients which happen to be listening, even if the corresponding mouse buttons were already up.

I don't know how (if at all) X.org keeps track of button states, so I'm not sure where best to fix this.  My local fix is simply to remove FlushButtons(), though this will leave buttons in a pressed state if they are pressed when the VT is switched (for example, from clicking a window manager's control button to change the active VT).