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 2867 - OS X: first mouse movement after entering relative mode has incorrect delta
Summary: OS X: first mouse movement after entering relative mode has incorrect delta
Status: RESOLVED INVALID
Alias: None
Product: SDL
Classification: Unclassified
Component: events (show other bugs)
Version: HG 2.0
Hardware: x86 Mac OS X (All)
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-05 09:42 UTC by Eric Wasylishen
Modified: 2015-02-05 20:32 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Wasylishen 2015-02-05 09:42:18 UTC
Steps to reproduce:
- launch the 'testrelative' sample app from Xcode. Notice where the cursor is when you launch the app.
- (don't move the mouse)
- when you see the sample app come up with the orange square in the middle, move the mouse just 1 or 2 pixels.

Expected:
- orange square moves slightly

Observed:
- orange square disappears - it's moved out of the bounds of the SDL window to the location where the mouse cursor was before the 'testrelative' app started running. If you move the mouse around you can bring it back into the SDL window.

Comments:

This seems to be done intentionally by SDL. It's trying to subtract out the warp from the initial mouse position to the center of the window that's done when relative mouse mode is engaged. But the problem is, the -deltaX/-deltaY of the NSEvent that comes in to Cocoa_HandleMouseEvent don't include the warp anyway.

See this comment in SDL_cocoamouse.m:

Cocoa_HandleMouseWarp(CGFloat x, CGFloat y)
{
    /* This makes Cocoa_HandleMouseEvent ignore the delta caused by the warp,
     * since it gets included in the next movement event.
     */
...

Commenting out this section of Cocoa_HandleMouseEvent seems to fix the issue:

    if (seenWarp) {
        deltaX += (lastMoveX - driverdata->lastWarpX);
        deltaY += ((CGDisplayPixelsHigh(kCGDirectMainDisplay) - lastMoveY) - driverdata->lastWarpY);

        DLog("Motion was (%g, %g), offset to (%g, %g)", [event deltaX], [event deltaY], deltaX, deltaY);
    }

Maybe that was needed on an older version of OS X?

But the docs for CGWarpMouseCursorPosition say "Moves the mouse cursor without generating events." - which sort of implies the warp won't show in deltaX/deltaY. Perhaps the SDL code was wrong all along, and the if (seenWarp) section can be safely removed?

Tested on OS X 10.10.2, SDL2 HG as to feb 5, 2015 (e29fec41a2c6)
Comment 1 Eric Wasylishen 2015-02-05 10:16:54 UTC
Hm, this bug doesn't happen if I repeat the same steps with the macbook's trackpad. Additionally, removing the "if (seenWarp) {}" block which fixed the issue when using a mouse, causes the bug to happen with the trackpad :-/
Comment 2 Eric Wasylishen 2015-02-05 20:32:29 UTC
Argh, sorry about this - I realized I had a third-party mouse driver installed (SmoothMouse). The issue went away when I uninstalled that, so I'll close this as "invalid".