Andreas Ragnerstam
I have two windows where one has a renderer where the logical size has been changed with SDL_RenderSetLogicalSize. When I get SDL_MOUSEMOTION events belonging to the non-scaled window these will have been scaled with the factor of the scaled window, which is not expected.
Adding some printf debugging to SDL_RendererEventWatch of SDL_render.c, where (event->type == SDL_MOUSEMOTION), I found that for every mouse motion SDL_RendererEventWatch is called twice and the event->motion.x and event.motion.y are set twice for the event, once for each renderer where only the last one set will be saved to the event struct. This will work fine if both renderers have the same scale, but otherwise the motion coordinates will be scaled for the renderer belonging to another window than the mouse was moved in.
I guess one solution would be to check that window == renderer->window for SDL_MOUSEMOTION events, similar to what is done for when SDL_WINDOWEVENT events.
I get the same error on both X11 and Windows.
The same problem also exists for SDL_MOUSEBUTTONDOWN and SDL_MOUSEBUTTONUP events.
Apparently you might get strange paths from GetModuleFileName(), such as
short path names or UNC filenames, so this avoids that problem. Since you have
to tapdance with linking different libraries and defining macros depending on
what Windows you plan to target, we dynamically load the API we need, which
works on all versions of Windows (on Win7, it'll load a compatibility wrapper
for the newer API location).
What a mess.
This also now does the right thing if there isn't enough space to store the
path, looping with a larger allocated buffer each try.
Fixes Bugzilla #2435.
Jason Wyatt
Currently the keymapnotify event handling is commented out as FIXME in SDL_x11events.c (It looks like this may have functioned SDL1.2).
Not handling this event means that if a window manager shortcut such as ALT+SPACE is used, SDL will send an ALT key down signal, but not an up signal. Also querying SDL about the key state, it believes the ALT key remains pressed.
X passes the events keypress (alt), ?focusout?, ?focusin?, keymapnotify.
This is a Win32-specific fix for bug 2726. A WinRT fix for this bug was applied
separately, via https://hg.libsdl.org/SDL/rev/91f56dcad879
This fix applies SDL_TOUCH_MOUSEID to 'mouse' events coming from touch devices,
but only when relative-mouse-mode is turned OFF. This bug is still present
when relative-mouse-mode is ON, however Microsoft does not provide documentation
on whether or not those input events (which come from WM_INPUT) can be
identified as touch-specific or not. Unofficially, that data might be available
(via GetMessageExtraInfo()), however this patch only uses MS-documented APIs.
Zack Middleton
Using X11 (on Debian Wheezy), SDL_GetModState() & KMOD_NUM and KMOD_CAPS are not set to system state (numlock/capslock LEDs). Pressing numlock or capslock toggles the mod state, though if num/caps lock is enabled before starting the program it's still reversed from system state. This makes getting KMOD_NUM and KMOD_CAPS in programs unreliable. This can be seen using the checkkeys test program.
The function that appears to have handle this in SDL 1.2 is X11_SetKeyboardState. The function call is commented out with "FIXME:" in SDL 2.
Using Windows backend through WINE; on first key press if numlock and/or capslock is enabled on system, numlock/capslock SDL_SendKeyboardKey is run and toggles KMOD_NUM/KMOD_CAPS to the correct state. On X11 this does not happen.
The attached patch makes X11 backend set keyboard state on window focus if no window was previously focused. It sets all keys to system up/down state and toggles KMOD_NUM/KMOD_CAPS via SDL_SendKeyboardKey to match system if needed. The patch is based on SDL 1.2's X11_SetKeyboardState.
Coriiander
Upon creating a window, a window property is added to it through the Win32-function "SetProp". This is done in the SDL-function "SetupWindowData" in file "src\video\windows\SDL_windowswindow.c".
Whenever you call "SetProp" to add a property to a Win32-window, you should also call the Win32-function "RemoveProp" to remove it before destroying that Win32-window.
While you might think that it's ok and that Windows will clean up nicely itself, it is not ok. It is against all Win32-API guidelines and is mostlikely a leak. Especially on external windows (CreateWindowFrom) you want to have things done right, not messy and leaky, affecting some other module. Even if SDL gets shutdown entirely that external window will now forever still have the "SDL_WindowData" prop attached to it.
The backing scale factor can change when the window moves between retina and non-retina displays.
The only other way to detect such a change is to compare the output of SDL_GL_GetDrawableSize or SDL_GetRendererOutputSize every frame, which is less than desirable, especially since the necessary app logic is likely already being executed when a window resize event is received.
This lets SDL-based apps respond to "Open With" commands properly, as they
can now obtain the requested path via a standard SDL dropfile event.
This is only checked on startup, so apps don't get drop events at any other
time, even if Android supports that, but this is still a definite
improvement.
Fixes Bugzilla #2762.
This apparently has fallout: the PS4 (and maybe PS3?) controllers apparently
report some bogus axes, but it won't change the axes we currently expect, and
thus the game controller config string is still stable.
Fixes Bugzilla #2719.
Since all device detection/removal happens on the main thread now, post events inline with when the status changes occur.
Also fixed rare cases when joystick API functions could return data about removed joysticks when called with a device index.
