Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDL_WM_Grab Input(SDL_GRAB_ON) breaks SDL Mouse Motion events on Windows in SDL 1.2.14 #618

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.14
Reported for operating system, platform: Windows (All), x86

Comments on the original bug report:

On 2011-03-01 14:00:35 +0000, Manuel Bilderbeek wrote:

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.

On 2011-03-03 08:58:10 +0000, Manuel Bilderbeek wrote:

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?

On 2011-03-05 09:59:59 +0000, Sam Lantinga wrote:

I'm not sure which patch fixed it, but you're welcome to use the SDL 1.2 snapshot in your game.

Cheers!

On 2011-03-05 14:28:14 +0000, Manuel Bilderbeek wrote:

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? :)

On 2011-03-05 14:40:36 +0000, Sam Lantinga wrote:

It should be fine. Is there any reason you don't want to just take the whole snapshot?

On 2011-03-05 14:55:44 +0000, Manuel Bilderbeek wrote:

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.

On 2011-03-05 19:29:48 +0000, Sam Lantinga wrote:

Fair enough! :)

On 2011-03-06 00:36:13 +0000, Manuel Bilderbeek wrote:

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...)

On 2011-03-07 14:11:03 +0000, Sam Lantinga wrote:

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant