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.

Correction: when the mouse hits the edge of the screen, events continue, but the erroneous values don't go beyond the edge of the screen.

The required functionality is not implemented (e.g. centering the cursor).

SDL_SetRelativeMouseMode(SDL_TRUE) returns 0 though, shouldn't it return -1?

I read somewhere Ryan mentioning that after 2.0.4, the minimum API level will rise to 14, so that SDL_ShowCursor() can work. Would this be true for warping the mouse position? Can we return -1 and set errors & mention this in the wiki until it's fixed?

This was in bug 2930. But I hope the target API will be changed and not the minimum API.

The wiki seems to be correct. SDL_SetRelativeMouseMode() is wrong. It checks for support of relative mode but there is none. It then seems to fall back to warping without checking if it is actually implemented and returns SDL_TRUE.

Thanks for clarifying Philipp. I've made a work-around for now.

I wouldn't mind the minimum APK rising to 14 if required.

At this point we can raise the minimum API level.
Does anyone have a tested patch for this issue?

I think there is no API to position mouse cursor on android, for this reason there is no WarpMouse function available in the android port.

Android doesn't provide relative mouse event, so SDL has to use the internal "relative_mode_warp".

Using relative_mode_warp without WarpMouse provide the behavior described in the first comment.

But this is still possible to have some consistent relative mode by not considering that the last point is always the screen center.

By doing: 

diff -r 2ce56475ad57 src/events/SDL_mouse.c
--- a/src/events/SDL_mouse.c	Tue Nov 07 09:10:32 2017 -0800
+++ b/src/events/SDL_mouse.c	Fri Nov 10 14:35:57 2017 +0100
@@ -274,6 +274,7 @@
     }
 
     if (mouseID != SDL_TOUCH_MOUSEID && mouse->relative_mode_warp) {
+        if (mouse->WarpMouse) {
         int center_x = 0, center_y = 0;
         SDL_GetWindowSize(window, &center_x, &center_y);
         center_x /= 2;
@@ -284,6 +285,7 @@
             return 0;
         }
         SDL_WarpMouseInWindow(window, center_x, center_y);
+        }
     }

But it should maybe just be reported as un-available : 
relative_mode_warp cannot be done without WarpMouse



diff -r 2ce56475ad57 src/events/SDL_mouse.c
--- a/src/events/SDL_mouse.c	Tue Nov 07 09:10:32 2017 -0800
+++ b/src/events/SDL_mouse.c	Fri Nov 10 14:56:37 2017 +0100
@@ -700,6 +700,11 @@
     SDL_Mouse *mouse = SDL_GetMouse();
     SDL_Window *focusWindow = SDL_GetKeyboardFocus();
 
+    /* No relative mouse mode possible */
+    if (ShouldUseRelativeModeWarp(mouse) && !mouse->WarpMouse) {
+        return -1;
+    }
+

That's all reasonable. Can the wiki be updated to explain this will return error on Android?

Looks like relative mouse events were added in API 24 (Android 7.0)
https://developer.android.com/reference/android/view/MotionEvent.html#AXIS_RELATIVE_X

> For a mouse, reports a difference of x position between the previous position. This is useful when pointer is captured, in that case the mouse pointer doesn't change the location but this axis reports the difference which allows the app to see how the mouse is moved.

Getting relative position can be done inside SDL, this relative_mode_warp.

But in your link, they talk also about the ability of hide the mouse pointer, this is :

https://developer.android.com/reference/android/view/View.html#requestPointerCapture()

But that's API 26 .. Android 8.0

Created attachment 3085 [details]
patch

Here's a patch to use SDL_SetRelativeMode() on Android.
to compile, you need a recent SDK and use compileSdkVersion 26.

It will work on platforms where SDK_INT >= 26. For older platforms SDL_SetRelativeMode will return -1 as not supported.

I've just tested this on 4.2.2 (Api 17) and SDL_SetRelativeMouseMode is still returning no error and proceeds to generate seemingly random xrel & yrel values...

I was testing 2.0.8 without the patch, so I guess the patch hasn't been applied yet?

It hasn't been merged.
Apply the patch locally to see whether it works and fits your needs.

Someone a re-done the patch, so closed:

https://hg.libsdl.org/SDL/rev/5b41aa10b12f
https://hg.libsdl.org/SDL/rev/d7cb1131aada