| Summary: | MouseWheel generates SDL_MOUSEBUTTONDOWN instead of SDL_MOUSEWHEEL | ||
|---|---|---|---|
| Product: | SDL | Reporter: | Dominik Tugend <dominik> |
| Component: | video | Assignee: | Ryan C. Gordon <icculus> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | icculus, metalcaedes, yalterz |
| Version: | 2.0.3 | Keywords: | target-2.0.4 |
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Attachments: | test program | ||
|
Description
Dominik Tugend
2015-05-17 20:04:52 UTC
(In reply to Dominik Tugend from comment #0) > Created attachment 2157 [details] > test program > > On reasonable fast PCs with multi threading there is a problem with test > programs (attached one) and also other progams using libSDL2 (i.e. the > current Half-Life Steam version): > MouseWheel generates SDL_MOUSEBUTTONDOWN with SDL_BUTTON_X1 / SDL_BUTTON_X2 > instead of SDL_MOUSEWHEEL. > > I am affected myself on a Gentoo system and know of two Arch Linux users > with the same problem. > > I am guessing that the problem is here: > http://hg.libsdl.org/SDL/file/b8d8f9674717/src/video/x11/SDL_x11events.c#l185 > in the X11_IsWheelEvent function, specifically with the X11_XPending call: > > When I break in that function named above with a debugger, then the > SDL_MOUSEWHEEL event gets generated as it should, but if I don't break with > a debugger, then it doesn't. > > So at the moment I am guessing, that there are often simply no pending > events that could be checked, meaning we cannot relay on the ButtonRlease > events being there already :( > > On my Gentoo system when not breaking in the debugger, I almost always get > the button events instead. > > For the two ArchLinux users, it seems to be more random, sometimes they get > button events and sometimes mouse wheel events with their test programs. > > Please let me know if I shall provide more information or s.th.. I'm one of the two Arch users mentioned. When I'm scrolling the wheel, the test program outputs sometimes the wheel messages properly, and sometimes _instead_ of another wheel message it outputs SDL_BUTTON_X2 for mwheeldown and SDL_BUTTON_X1 for mwheelup. In Half-Life, I get it way more often and it is, respectively, mouse5 instead of mwheeldown and mouse4 instead of mwheelup. We were checking things with xev, and it outputs wheel messages as ButtonPress immediately followed by ButtonRelease with identical time, as it should, without any errors. I've observed the problem as well. Probably sometimes, for whatever reason, the X11 button up event for the wheel does not happen at the same time as the button down event, but maybe in the next frame or something (so it still looks like "immediately" in xev). I think X11 buttons 4 and 5 should always be recognized as wheel up/down and 6 and 7 as wheel left/right, without the call to X11_XCheckIfEvent() This problem has also been discussed in https://bugzilla.libsdl.org/show_bug.cgi?id=2472 and while removing this change for the 2.0.4 release seems to risky, it'll probably be removed afterwards, so it'll be in 2.0.5 if it doesn't cause any trouble. (if it does cause trouble, i.e. sometimes X11 buttons 4-7 are not actually vertical/horizontal scrollwheel events, XInput2 could be queried for the key names of those buttons to be sure of their meaning, I also described that in the other report) This is now fixed in https://hg.libsdl.org/SDL/rev/ca64802fd9b0 --ryan. hmm in "case ButtonRelease:" shouldn't SDL_SendMouseButton(...) be within if(!X11_IsWheelEvent(...)) { ... } ?
otherwise it will send a button event anyway and the comment is wrong.
Ryan corrected it in https://hg.libsdl.org/SDL/rev/bf7734a34f13 I compiled and tried that version (using LD_LIBRARY_OATH) with the test program and it worked fine. Thank you for fixing the problem. |