Bug 13930 - xf86-input-mouse generates spurious ButtonRelease events on VT switch
Summary: xf86-input-mouse generates spurious ButtonRelease events on VT switch
Status: RESOLVED DUPLICATE of bug 13144
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/Mouse (show other bugs)
Version: 7.3 (2007.09)
Hardware: All All
: medium minor
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-01-04 10:20 UTC by Andrew Church
Modified: 2008-01-04 17:30 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Church 2008-01-04 10:20:55 UTC
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).
Comment 1 Julien Cristau 2008-01-04 17:30:41 UTC

*** This bug has been marked as a duplicate of bug 13144 ***


bug/show.html.tmpl processed on Mar 29, 2017 at 19:03:34.
(provided by the Example extension).