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)