GNOME Bugzilla – Bug 680088
Duplicate mouse wheel scroll events with xinput enabled
Last modified: 2012-07-17 14:16:16 UTC
Created attachment 219010 [details] Test case for duplicate xinput scroll events Running the attached program with and without XI2 enabled and scrolling the mouse wheel dow/up/down results in: $ ./scroll SCROLL (direction:down) SCROLL (direction:up) SCROLL (direction:down) ^C $ ./scroll --enable-xinput SCROLL (direction:smooth dx:0,00 dy:0,000000) SCROLL (direction:down) SCROLL (direction:down) SCROLL (direction:smooth dx:0,00 dy:-1,000000) SCROLL (direction:up) SCROLL (direction:up) SCROLL (direction:smooth dx:0,00 dy:1,000000) SCROLL (direction:down) SCROLL (direction:down) Note that in the second invocation the non-smooth scroll events are duplicated even if I've applied the same amount of wheel clicks in both cases.
the X server is sending multiple synthetic ButtonPress events (that we'll translate into ClutterScrollEvent) to make up for the smooth scrolling delta: [scroll starts] -------> physical space -------> [scroll end] | threshold | threshold | threshold | threshold | threshold [ButtonPress] [ButtonPress] [ButtonPress] which, thinking about it, makes sense if you want to maintain a spatial relationship between the scrolling on the device and the scrolling on the window all the while keeping existing code using discrete scrolling code working with devices that have smooth scrolling capabilities, instead of simply breaking them (which was the approach favoured by Apple).
actually, no: looking at the event translation code we generate ClutterScrollEvent on XI_ButtonPress *and* XI_ButtonRelease, which is wrong.
Created attachment 219022 [details] [review] x11/xi2: Do not generate scroll events on ButtonRelease Scroll events are generated on ButtonPress only in the core event handling, so it should happen the same if we use XInput.
Attachment 219022 [details] pushed as 2a31a93 - x11/xi2: Do not generate scroll events on ButtonRelease