This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

• mouse-wheel-false-positives.diff (mouse-wheel-false-positives.diff, text/plain, 2013-09-22 20:30:21 +0000, 2015 bytes)

Reported in version: 2.0.0
Reported for operating system, platform: Linux, x86_64

Comments on the original bug report:

On 2013-09-22 20:30:21 +0000, wrote:

Created attachment 1335
mouse-wheel-false-positives.diff

This was reported in Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723797

Patch suggested by Darren attached. Please advise before we incorporate it in Debian.

---

Reported by: Darren Salt bugspam@moreofthesa.me.uk

I've noticed that one mouse button, which was fine with SDL 1.2, didn't
appear to be working when using SDL 2.0.

Some digging showed that it's a consequence of two things: how SDL2 detects
mouse wheel usage, and a kernel patch to work around a problem with the mouse
in question regarding that button.

Since the mouse does not generate a release event when that button is
released (this appears to be by design), release events need to be
synthesised in order to avoid confusing X into thinking that a drag operation
is in progress when that button is pressed. This causes press time == release
time, and tricks SDL2 into handling it as a wheel – but, since SDL2 ‘knows’
elsewhere that Button4 and Button5 are the only possible wheel buttons, the
event is effectively discarded (it is sent with wheel.y = 0 and the button
information is lost).

(While investigating this, I noticed that the horizontal wheel ISN'T picked
up as a mouse wheel and, consequently, works without problems with SDL2 – it
fails the press time == release time test so doesn't fall foul of SDL2's X11
code only knowing about the vertical scroll wheel.)

On 2013-09-28 06:37:44 +0000, Sam Lantinga wrote:

Yes, this patch looks good and is in for the 2.0.1 release.
http://hg.libsdl.org/SDL/rev/6073ad385c9b

Thanks!