This bug report was migrated from our old Bugzilla tracker.

Reported in version: HG 2.1
Reported for operating system, platform: Mac OS X 10.8, x86_64

Comments on the original bug report:

On 2013-10-11 16:32:51 +0000, Mitchell Keith Bloch wrote:

Setting SDL_SetWindowGrab(SDL_TRUE) seems to allow the mouse to leave the window. It's not as if it weren't set at all, but the cursor flickers outside the window, and it is possible to click on things outside the window. i.e. It is possible to click on the Apple menu in the upper left, pulling up the menu briefly before the cursor flickers again, automatically closing the window.

On 2013-10-12 00:06:18 +0000, Mitchell Keith Bloch wrote:

Actually, it's the same problem on Linux. Windows seems to be fine.

On 2013-10-12 06:11:32 +0000, Mitchell Keith Bloch wrote:

SDL_SetRelativeMouseMode(SDL_TRUE) seems to be broken on Linux and Mac OS X as well. In Linux, I get no mouse motion events whatsoever unless I disable the if(!mouse->relative_mode) check in SDL_x11events.c, case MotionNotify. I can't seem to find a workaround.

On 2013-10-12 08:14:36 +0000, Alex Szpakowski wrote:

On OS X have you tried building SDL2 with SDL_MAC_NO_SANDBOX defined? Doing so enables better mouse grabbing code, at the cost of being unable to use the library in a program published in the Mac App Store apparently.

On 2013-10-13 05:17:00 +0000, Mitchell Keith Bloch wrote:

Ha, interesting. So, I added "#define SDL_MAC_NO_SANDBOX 1" to SDL_config_macosx.h, recompiled, and retested. It is better, but still badly broken.

-I still get hover events outside the window, as can be seen clearly when the mouse moves over the dock at the bottom of the screen.
+Mouse clicks no longer escape the window.
-Instead, when the mouse is at the edge, it seems to generate window resize events. This is still broken behavior, but I suppose it could be mitigated by not making the window resizable in the first place.

As an amendment to my previous concern regarding SDL_SetRelativeMouseMode(SDL_TRUE), when I disable the check I mentioned before, I get broken behavior. (No surprise?) This broken behavior seems to mirror broken behavior present on Mac OS X (with no alterations on my part). The xrel and yrel values seem to be some sort of absolute coordinates, so if the mouse is near the center of the window, the xrel and yrel values are small, and the if the mouse is near the frame, the values are large positive or negative numbers. It's very confusing to get large, positive xrel values when moving the mouse left near the right edge of the window. Something is very wrong.

None of these issues is present in Windows, mercifully.

On 2013-11-08 21:05:48 +0000, Mitchell Keith Bloch wrote:

Unless there's a workaround that hasn't been presented here, this bug makes it impossible to create a simple FPS with mouse-turn controls on Mac OS X and Linux. This is a pretty serious regression in functionality from SDL 1.2.x. Is there any chance I could get some help with this?

On 2013-11-10 22:15:45 +0000, Sam Lantinga wrote:

Yes, we're going to help you with this. Jorgen, can you take a look at the Mac OS X issue? I'm going to look at the Linux code.

On 2013-11-17 05:12:47 +0000, Sam Lantinga wrote:

Mitchell, I'm not seeing the same mouse issues you are here, on Mac OS X 10.9
I'm testing by commenting out the return at the top of SDLTest_PrintEvent() in SDL_test_common.c, and then running testwm2 --info event --resize, and using Ctrl-G to grab the mouse and Ctrl-R to toggle relative mode.

Here are my results:

• Grabbing the mouse but leaving relative mode off:

• moving the mouse to the edge of the screen allowed me to resize the window. This isn't ideal results and doesn't match the way other platforms behave, but seems to be standard behavior for Mac OS X windows.
• Occasionally if I move fast enough I can get the mouse out of the window, but it is immediately warped back in. If I define SDL_MAC_NO_SANDBOX, this behavior is fixed.
• Absolute and relative coordinates seem sane, e.g. relative motion is large if I move the mouse fast, small if I move the mouse slowly. Relative motion stops when I reach the edge of the window.

• Turning on relative mode:

• The cursor flickers to the center of the window and vanishes
• I can't get the mouse out of the window
• I can't "grab" the edge of the window to resize it
• Absolute and relative coordinates seem sane, e.g. relative motion is large if I move the mouse fast, small if I move the mouse slowly. Relative motion continues when I reach the edge of the window according to the absolute coordinates.

One difference I noticed with SDL_MAC_NO_SANDBOX enabled is that it clamps the cursor to the whole window including the title bar, not just the client area.

I didn't see any issues that would prevent a shooter, and specifically I was never able to reproduce the large relative motion values you reported.

On 2013-11-17 23:53:09 +0000, Mitchell Keith Bloch wrote:

(In reply to Sam Lantinga from comment # 7)

I'm testing by commenting out the return at the top of SDLTest_PrintEvent()
in SDL_test_common.c, and then running testwm2 --info event --resize, and
using Ctrl-G to grab the mouse and Ctrl-R to toggle relative mode.

Alright. I can do that too. Things seem better on Mac OS 10.9 than when I last tested this. I don't know if it's improved because it's not 10.8 anymore, or if something changed in the code. Grabbed seems okay. Relative I'm unsure about, but I'll try to confirm tomorrow.

On Linux, I've redone a couple tests. My results are still peculiar. On a Linux Mint 13 system, grabbed seems to work fine, while the relative toggle seems to have no effect. (It remains grabbed or not grabbed, and the cursor warps back to the center of the window.) On an LMDE virtual machine in VirtualBox, however, I'm not getting any mouse motion events at all, but mouse button events are reported just fine.

On 2013-11-18 00:59:48 +0000, Sam Lantinga wrote:

On Linux you also need to grab to get relative motion events. I have automatically grabbing as part of setting relative mode on my TODO list, but I haven't implemented it yet.

You also can't reliably test relative mode in a VM, which is one of the reasons I haven't gotten to it yet. :)

On 2013-11-18 19:21:26 +0000, Mitchell Keith Bloch wrote:

(In reply to Sam Lantinga from comment # 9)

On Linux you also need to grab to get relative motion events. I have
automatically grabbing as part of setting relative mode on my TODO list, but
I haven't implemented it yet.

That's good to know. In any case, relative mouse motion being broken on Linux is the only significant part of this bug report that still appears to be valid. I can confirm that things appear to be working at the moment on a native OS 10.8.4 system.

You also can't reliably test relative mode in a VM, which is one of the
reasons I haven't gotten to it yet. :)

That's a downer. I know I've had mouse issues in my VMs before, but I used to get at least some mouse events on Linux before the switch to 2.0. Oh well. Thanks for all the help, and sorry for the couple of red herrings.

On 2013-11-18 19:49:32 +0000, (disabled) Jørgen Tjernø wrote:

Resetting assignee to default, since this isn't Mac-related.

On 2014-02-09 20:33:50 +0000, Sam Lantinga wrote:

I implemented the proper mouse grab and warping mode on Linux. Can you retest this?

On 2014-02-12 20:54:35 +0000, Mitchell Keith Bloch wrote:

(In reply to Sam Lantinga from comment # 12)

I implemented the proper mouse grab and warping mode on Linux. Can you
retest this?

I'm sorry to report no evidence of improvement. My code receives mouse motion events (until the mouse hits the edge of the window) if I simply grab and hide the mouse, but none at all if it enters relative mode.

On 2014-02-23 01:47:29 +0000, Sam Lantinga wrote:

Are you testing in a VM or on an actual Linux installation? The VM mouse driver may not support the relative mode API we're using.

You can test this hypothesis by setting the environment variable SDL_MOUSE_RELATIVE_MODE_WARP=1 and seeing if you get mouse events again.

On 2014-02-23 21:32:56 +0000, Mitchell Keith Bloch wrote:

I haven't tested in a VM in quite some time. When I tested on a physical machine, I received no mouse motion events in relative mode.

On 2015-03-25 07:02:01 +0000, Jacob Welsh wrote:

I am also seeing strange behavior with relative mouse mode on Linux, though different from what was previously described here. Motion events appear to be duplicated, for example, moving the mouse one pixel to the right results in two move events each with xrel=1. Same if it's more than one pixel at a time: they always come in pairs with matching xrel/yrel.

With SDL_MOUSE_RELATIVE_MODE_WARP=1 it works correctly.

Physical machine, Fedora 20, X server 1.14.4. Same results with both USB mouse and touchpad.

On 2018-08-06 21:20:22 +0000, Ryan C. Gordon wrote:

Hello, and sorry if you're getting dozens of copies of this message by email.

We are closing out bugs that appear to be abandoned in some form. This can happen for lots of reasons: we couldn't reproduce it, conversation faded out, the bug was noted as fixed in a comment but we forgot to mark it resolved, the report is good but the fix is impractical, we fixed it a long time ago without realizing there was an associated report, etc.

Individually, any of these bugs might have a better resolution (such as WONTFIX or WORKSFORME or INVALID) but we've added a new resolution of ABANDONED to make this easily searchable and make it clear that it's not necessarily unreasonable to revive a given bug report.

So if this bug is still a going concern and you feel it should still be open: please feel free to reopen it! But unless you respond, we'd like to consider these bugs closed, as many of them are several years old and overwhelming our ability to prioritize recent issues.

(please note that hundred of bug reports were sorted through here, so we apologize for any human error. Just reopen the bug in that case!)

Thanks,
--ryan.

On 2018-09-29 20:30:51 +0000, wrote:

This is still a problem on libsdl 2.0.8 on Ubuntu Linux 18.04.1 in a VMware Fusion virtual machine, xrel and yrel are large positive values when setting SDL_SetRelativeMouseMode(SDL_TRUE), but the same workaround still works:

SDL_SetHintWithPriority(SDL_HINT_MOUSE_RELATIVE_MODE_WARP, "1", SDL_HINT_OVERRIDE);

Found this tip at https://stackoverflow.com/questions/25576438/sdl-getrelativemousestate-strange-behaviour

On 2018-09-29 20:46:11 +0000, Ryan C. Gordon wrote:

(In reply to ice_ix from comment # 18)

This is still a problem on libsdl 2.0.8 on Ubuntu Linux 18.04.1 in a VMware
Fusion virtual machine, xrel and yrel are large positive values when setting
SDL_SetRelativeMouseMode(SDL_TRUE), but the same workaround still works:

I think this particular issue should be discussed over at Bug # 2954, and we'll leave this old bug report abandoned.

--ryan.