We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 1158

Summary: SDL_WM_Grab Input(SDL_GRAB_ON) breaks SDL Mouse Motion events on Windows in SDL 1.2.14
Product: SDL Reporter: Manuel Bilderbeek <manuel>
Component: videoAssignee: Sam Lantinga <slouken>
Status: RESOLVED FIXED QA Contact: Sam Lantinga <slouken>
Severity: major    
Priority: P2    
Version: 1.2.14   
Hardware: x86   
OS: Windows (All)   

Description Manuel Bilderbeek 2011-03-01 14:00:35 UTC 
After enabling Grab_Input on Windows with SDL 1.2.14, all following Mouse Motion events only have 324, 291 as xrel and yrel motion values. (I printed the values from openMSX, directly where we receive this from SDL.)

This worked fine in SDL 1.2.13, so it's a regression. It also works fine on e.g. Linux.

See also https://sourceforge.net/tracker/?func=detail&aid=3196573&group_id=38274&atid=421861 for the corresponding bug in openMSX.
Comment 1 Manuel Bilderbeek 2011-03-03 08:58:10 UTC 
My friends confirm it is fixed with the snapshot of the new SDL 1.2.

Can someone point me to the patch/commit/fix that resolved it?
Comment 2 Sam Lantinga 2011-03-05 09:59:59 UTC 
I'm not sure which patch fixed it, but you're welcome to use the SDL 1.2 snapshot in your game.

Cheers!
Comment 3 Manuel Bilderbeek 2011-03-05 14:28:14 UTC 
I do know which patch fixed it: this one: http://hg.libsdl.org/SDL/rev/07b330419439

We are now applying this patch to SDL 1.2.14 to fix the issue. See http://openmsx.svn.sourceforge.net/viewvc/openmsx/openmsx/trunk/build/3rdparty/SDL-1.2.14.diff?r1=11981&r2=11980&pathrev=11981

Do you think that is a smart thing to do? :)
Comment 4 Sam Lantinga 2011-03-05 14:40:36 UTC 
It should be fine.  Is there any reason you don't want to just take the whole snapshot?
Comment 5 Manuel Bilderbeek 2011-03-05 14:55:44 UTC 
Yes, we have a 3rd party system which automatically downloads, configures and compiles all dependencies to build a statically linked binary. That snapshot has no status and can be removed at any time. Which will then break the 'staticbindist' compilation.
Also, we are on the virge of a release, so it would be a bit risky to upgrade one of the most important libraries we use on such short notice.
Comment 6 Sam Lantinga 2011-03-05 19:29:48 UTC 
Fair enough! :)
Comment 7 Manuel Bilderbeek 2011-03-06 00:36:13 UTC 
Note that for some reason beyond my comprehension, applying that patch in combination from the patch Max mentioned in bug 956 has bad effects: the patch doesn't work. So, we removed that patch from bug 956 and only applied the one mentioned in this bug report. And it appears that that also fixed the issue mentioned in bug 956.

Does that sound sane to you, Sam? (Just checking here...)
Comment 8 Sam Lantinga 2011-03-07 14:11:03 UTC 
Looking over it, I don't understand exactly why that would be, but the fix for this bug is a more comprehensive fix and could fix strangeness in other areas.

I'll go ahead and mark that other bug fixed, thanks!