Laurent Merckx
I have a problem with the SDL_ShowCursor method on Raspberry.
Depending on the context, my application hides or show the mouse cursor with SDL_ShowCursor.
But when calling SDL_ShowCursor(true), the cursor is displayed at 0,0 (and not at last position).
After debugging sources by myself, it seems that the problem is in SDL_rpimouse.c - RPI_ShowCursor:
vc_dispmanx_rect_set( &dst_rect, 0, 0, curdata->w, curdata->h);
should be
vc_dispmanx_rect_set( &dst_rect, mouse->x, mouse->y, curdata->w, curdata->h);
For me, it solves the problem.
tomwardio
HAVE_POLL is correctly defined in SDL_config.h when running configure. However, in the only place where it's used, it's undefined at the start of the file.
Dominik Reichardt
As discussed in 2012 the iOS onscreen keyboard hides when you hit RETURN (see https://discourse.libsdl.org/t/on-screen-keyboard-change/19216).
IMO this is a bad idea to not be able to influence this behavior and just recently this was fixed for Android by adding the hint SDL_HINT_ANDROID_RETURN_HIDES_IME in changeset 11768 0f2fb9ec6ad6.
Eric wing
There is a tiny bug in the new overscan code for the SDL_renderer.
In SDL_renderer.c, line 1265, the if check for SDL_strcasecmp with "direct3d" needs to be inverted.
Instead of:
if(SDL_strcasecmp("direct3d", SDL_GetCurrentVideoDriver())) {
It should be:
if(0 == SDL_strcasecmp("direct3d", SDL_GetCurrentVideoDriver())) {
This bug causes the "overscan" mode to pretty much be completely ignored in all cases and all things remain letterboxed (as before the feature).
bastien.bouclet
According to this GCC bug report, altivec.h requires building with the gnu extensions: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78263.
As an application developer, I don't want SDL to force me to enable the gnu extensions.
Elisée Maurer
The attached minimal program sets the SDL_HINT_MOUSE_RELATIVE_MODE_WARP to 1, enables relative mouse mode then logs all SDL_MOUSEMOTION xrel values as they happen.
When moving the mouse exclusively to the right:
* On a Windows 10 installation before Fall Creators update (for instance, Version 10.0.15063 Build 15063), only positive values are reported, as expected
* On a Windows 10 installation after Fall Creators update (for instance, Version 10.0.16299 Update 16299), a mix of positive and negative values are reported.
3 different people have reproduced this bug and have confirmed it started to happen after the Fall Creators update was installed. It happens with SDL 2.0.7 as well as latest default branch as of today.
It seems like some obscure (maybe unintended) Windows behavior change? Haven't been able to pin it down more yet.
(To force-upgrade a Windows installation to the Fall Creators update, you can use the update assistant at https://www.microsoft.com/en-us/software-download/windows10)
Eric Wasylishen
Broken GetCursorPos / SetCursorPos based games on Win 10 fall creators are not limited to SDL.. I just tested winquake.exe (original 1997 exe) and it now has "jumps" in the mouse input if you try to look around in a circle. It uses GetCursorPos/SetCursorPos by default. Switching WinQuake to use directinput (-dinput flag) seems to get rid of the jumps.
Daniel Gibson
A friend tested on Win10 1607 (which is before the Fall Creators Update) and the the bug doesn't occur there, so the regression that SetCursorPos() doesn't reliably generate mouse events was indeed introduced with that update.
I even reproduced it in a minimal WinAPI-only application (https://gist.github.com/DanielGibson/b5b033c67b9137f0280af9fc53352c68), the weird thing is that if you don't do anything each "frame" (i.e. the mainloop only polls the events and does nothing else), there are a lot of mouse events with the coordinates you passed to SetCursorPos(), but when sleeping for 10ms in each iteration of the mainloop, those events basically don't happen anymore. Which is bad, because in games the each iteration of the mainloop usually takes 16ms..
I have a patch now that I find acceptable.
It checks for the windows version with RtlGetVersion() (ff561910.aspx) and only if it's >= Win10 build 16299, enables the workaround.
All code is in video/windows/SDL_windowsevents.c
and the workaround is, that for each WM_MOUSEMOVE event, "if(isWin10FCUorNewer && mouseID != SDL_TOUCH_MOUSEID && mouse->relative_mode_warp)", an addition mouse move event is generated with the coordinates of the center of the screen
(SDL_SendMouseMotion(data->window, mouseID, 0, center_x, center_y);) - which is exactly what would happen if windows generated those reliably itself.
This will cause SDL_PrivateSendMouseMotion() to set mouse->last_x = center_x; and mouse->last_y = center_y; so the next mouse relative mouse event will be calculated correctly.
If Microsoft ever fixes this bug, the IsWin10FCUorNewer() function would have to
be adjusted to also check for a maximum version, so the workaround is then disabled again.
