Package: libsdl2-2.0-0 Version: 2.0.0+dfsg1-2 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.) -- | _ | Darren Salt, using Debian GNU/Linux (and Android) | ( ) | | X | ASCII Ribbon campaign against HTML e-mail | / \ | http://www.asciiribbon.org/ You will find many bugs today.
# User Darren Salt <devs...@moreofthesa.me.uk> # Date 1379621782 -3600 # Thu Sep 19 21:16:22 2013 +0100 Work around a false-positive in the X11 mouse wheel code This false positive occurs when one particular button on my mouse is pressed. The kernel which I'm using is patched to cause a release event to be synthesised immediately when the mouse says that this button is pressed because the mouse doesn't signal release until the button is next pressed. (Also documents a false negative, observed with the horizontal scroll wheel on the same mouse.) diff -ur libsdl2-2.0.0+dfsg1.orig/src/video/x11/SDL_x11events.c libsdl2-2.0.0+dfsg1/src/video/x11/SDL_x11events.c --- libsdl2-2.0.0+dfsg1.orig/src/video/x11/SDL_x11events.c 2013-09-19 21:36:30.000000000 +0100 +++ libsdl2-2.0.0+dfsg1/src/video/x11/SDL_x11events.c 2013-09-19 21:34:59.582201080 +0100 @@ -135,7 +135,9 @@ XPointer arg) { XEvent *event = (XEvent *) arg; + /* we only handle buttons 4 and 5 - false positive avoidance */ if (chkev->type == ButtonRelease && + (event->xbutton.button == Button4 || event->xbutton.button == Button5) && chkev->xbutton.button == event->xbutton.button && chkev->xbutton.time == event->xbutton.time) return True; @@ -150,7 +152,12 @@ however, mouse wheel events trigger a button press and a button release immediately. thus, checking if the same button was released at the same time as it was pressed, should be an adequate hack to derive a mouse - wheel event. */ + wheel event. + However, there is broken and unusual hardware out there... + - False positive: a button for which a release event is + generated (or synthesised) immediately. + - False negative: a wheel which, when rolled, doesn't have + a release event generated immediately. */ if (XCheckIfEvent(display, &relevent, X11_IsWheelCheckIfEvent, (XPointer) event)) {