kmx git

Commit	Date	Message
19dee1cd	2021-10-22T06:37:20	Add SDL_GetWindowICCProfile(). (#4314) * Add SDL_GetWindowICCProfile * Add new SDL display events * Implement ICC profile change event for macOS * Implement ICC profile notification for Windows * Fix SDL_GetWindowICCProfile() for X11 * Fix compile errors
bfd2f899	2021-10-19T17:29:23	Fixed grab handling when focus changes between windows in the same application
7fb43643	2021-10-17T13:56:31	Don't process WM_INPUT when handling relative mode by warping the mouse cursor
06824b18	2021-10-17T19:50:39	Cleanup windows events after recent changes Improves clarity without any functional changes
a70a94e0	2021-10-15T18:11:19	Don't send a mouse leave event if the mouse is outside the window when gaining focus and in relative mode.
c583055a	2021-10-15T10:11:24	SDL_windowsevents.c (WIN_WindowProc): remove SAFE_AREA_X and SAFE_AREA_Y Not used since commit https://github.com/libsdl-org/SDL/commit/a1fabca162091b50d6f7dd71879d028319e09d80
a1fabca1	2021-10-14T16:52:21	Removed mouse warping for local mice and improved warp handling for mouse over RDP
5e89b3c8	2021-10-14T11:46:07	Don't need to use raw input to track the mouse during mouse capture (thanks Brick!)
0b6a8211	2021-10-12T14:08:20	Messages posted on the same tick are not new
6149e601	2021-10-13T00:03:56	remove IsWin10FCUorNewer() -- not used since commit 40ed9f75c9e1ed
311671a0	2021-10-12T23:50:02	fixed build after commit 6e356e20ad
6e356e20	2021-10-12T18:35:52	Fix mouse focus being set to null when a captured mouse cursor leaves the window.
40ed9f75	2021-10-08T10:05:27	Workaround for Windows occasionally ignoring SetCursorPos() calls Also, since we're flushing mouse motion before and including the warp, we don't need the isWin10FCUorNewer hack to simulate mouse warp motion. Fixes https://github.com/libsdl-org/SDL/issues/4339 and https://github.com/libsdl-org/SDL/issues/4165
16aeb8d0	2021-10-07T15:04:06	Guarantee that we don't dispatch any mouse motion from before or including the last mouse warp
dd95c9c8	2021-10-06T09:09:39	Moved focus click check into WIN_UpdateFocus() so we have the correct state when setting keyboard focus Fixes https://github.com/libsdl-org/SDL/issues/4817
0d541e5a	2021-10-06T00:36:27	Revert "Fixed relative mode mouse events stopping if you click on the title bar" This has been better fixed by b28ed02 or another related relative mouse mode change of @slouken in SDL 2.0.17 and as such can be reverted to reduce unneeded processing in WM_MOUSEMOVE
c542de92	2021-10-05T14:08:36	React to WM_NCACTIVATE instead of WM_SETFOCUS or WM_ACTIVATE for focus changes See https://github.com/libsdl-org/SDL/pull/4293 and https://github.com/libsdl-org/SDL/issues/4450 for details
632aca29	2021-10-01T16:17:38	Window input focus is based on WM_SETFOCUS and WM_KILLFOCUS as WM_ACTIVATE doesn't necessarily imply focus. Hopefully resolves https://github.com/libsdl-org/SDL/issues/4450 and https://github.com/libsdl-org/SDL/pull/4293
477fcf52	2021-09-24T10:49:46	Fixed whitespace
db68af80	2021-09-24T10:49:44	Reduce the likelyhood that the mouse will hover over the taskbar or toast notification while in relative mode, which causes a mouse leave event. This will still happen occasionally as the mouse is whipped around, if there is a window overlapping the game window, but it should happen less often now. This could even happen with the original code that warped the mouse every frame, so this should be a good compromise where we don't warp the mouse continously and we still keep the mouse in the safe area of the game window. Note that notifications can be any size, so the safe area may need to be adjusted or even dynamically defined via a hint.
287571fb	2021-09-22T17:40:57	Limit effect of in_title_click and focus_click_pending to only blocking cursor warping; without this all relative mouse motion was getting ignored when a window was activated via a mouse button
5d455cab	2021-09-21T18:15:11	Don't process raw input when the window is being dragged or clicked on.
0fd54f91	2021-09-21T18:15:11	Fixed using a tablet with raw input relative motion Tested with a Wacom Cintiq Pro 16"
8fee82d1	2021-09-21T18:15:09	Improve relative motion handling over RDP CR and research: @danielj
ccb06296	2021-08-19T03:15:02	SDL_windowsevents.c: fix build against older SDKs.
91a55a02	2021-08-13T23:59:39	Relative mouse motion is delivered to the window with keyboard focus This was the original intent (note SDL_UpdateWindowGrab() in SDL_OnWindowFocusGained() and SDL_OnWindowFocusLost()) and fixes a bug where relative motion unexpectedly stops if the task bar is covering the bottom of the game window and the mouse happens to move over it while relative mode is enabled. Another alternative would be to confine the mouse when relative mode is enabled, but that generates mouse motion which would need to be ignored, and it's possible for the user moving the mouse to combine with the mouse moving into the confined area so you can't easily tell whether to ignore the mouse motion. See https://github.com/libsdl-org/SDL/issues/4165 for a case where this is problematic.
4d9efcb5	2021-08-13T11:52:25	Fixed flag test for boolean correctness
b28ed028	2021-08-13T11:39:41	Don't warp the mouse for relative mode when the window doesn't have focus
cb1e20b0	2021-08-10T17:50:17	Added KMOD_SCROLL to track the scroll lock state Fixes https://github.com/libsdl-org/SDL/issues/4566
cb0fd05e	2021-08-07T22:41:54	Adding a clarifying comment in case a programmer unfamiliar with UTF-16 and UTF-32's relationship chances upon the code.
34701129	2021-08-07T20:51:49	Optimizing the implementation.
712e0d1f	2021-08-07T16:23:15	Fixing WM_CHAR event handling for Unicode characters outside the Basic Multilingual Plane.
41e1a236	2021-07-27T16:50:06	Correct the maximized size and position for borderless resizable windows This fixes bug https://github.com/libsdl-org/SDL/issues/4043
3b85e3fd	2021-07-24T15:47:11	Fixed internal Windows key state when using Windows+Space or Windows+G shortcuts This fixes bugs: https://github.com/libsdl-org/SDL/issues/4369 https://github.com/libsdl-org/SDL/issues/4500
c2e8a791	2021-06-12T16:20:47	SDL_windowsevents: add support for multiple mice
85b51e6c	2021-06-05T11:46:47	Fall back to polling normally if not operating the win32 message loop In this condition, we cannot safely wait/wake on events.
0dd7024d	2021-03-12T21:58:20	Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling When possible use native os functions to make a blocking call waiting for an incoming event. Previous behavior was to continuously poll the event queue with a small delay between each poll. The blocking call uses a new optional video driver event, WaitEventTimeout, if available. It is called only if an window already shown is available. If present the window is designated using the variable wakeup_window to receive a wakeup event if needed. The WaitEventTimeout function accept a timeout parameter. If positive the call will wait for an event or return if the timeout expired without any event. If the timeout is zero it will implement a polling behavior. If the timeout is negative the function will block indefinetely waiting for an event. To let the main thread sees events sent form a different thread a "wake-up" signal is sent to the main thread if the main thread is in a blocking state. The wake-up event is sent to the designated wakeup_window if present. The wake-up event is sent only if the PushEvent call is coming from a different thread. Before sending the wake-up event the ID of the thread making the blocking call is saved using the variable blocking_thread_id and it is compared to the current thread's id to decide if the wake-up event should be sent. Two new optional video device methods are introduced: WaitEventTimeout SendWakeupEvent in addition the mutex wakeup_lock which is defined and initialized but only for the drivers supporting the methods above. If the methods are not present the system behaves as previously performing a periodic polling of the events queue. The blocking call is disabled if a joystick or sensor is detected and falls back to previous behavior.
157c3f80	2021-05-21T09:45:08	[SDL] Minimize number of system calls when handling WM_INPUT raw input messages. Details: Currently doing 4 system calls per WM_INPUT message, which can cause the thread handling the message loop to be swapped out several times: * GetProp - to get window data from the window handle * GetRawInputData - to retrieve the raw input data * 2 calls to GetMessageExtraInfo - to ignore synthetic mouse events generated for touchscreens In this change: * Replaced GetProp by iterating the list of windows maintained by SDL (with a fallback to GetProp). Note that this will affect all messages and not just WM_INPUT * only calling GetMessageExtraInfo if a touchscreen has been detected Fix for https://jira.valve.org/browse/CSGO-4855 @saml
89b62093	2021-04-01T14:17:53	Fix race condition that can lead to ENTER/LEAVE window events never firing On windows, when toggling the state of RelativeMode rapidly, there is a high chance that SDL_WINDOWEVENT_ENTER / SDL_WINDOWEVENT_LEAVE events will stop firing indefinitely. This aims to resolve that shortcoming by ensuring mouse focus state is correctly updated via WM_MOUSELEAVE events arriving via the windows event hook.
a78bce9e	2021-01-28T20:02:01	Properly handle keys already down when the hook is installed For keys that are already down when we install the keyboard hook, we need to allow the WM_KEYUP/WM_SYSKEYUP message to be processed normally. This ensures that other applications see the key up, which prevents the key from being stuck down from the perspective of other apps when our grab is released.
2793c9cf	2021-01-25T18:40:26	Fix grabbing Alt+Tab and Alt+Esc on Windows 7
141f4416	2021-01-24T03:55:04	fix build failure due to -Werror=declaration-after-statement (bug #5500)
8c921d82	2021-01-22T19:40:26	Implement keyboard grab support for Windows This is implemented via a low-level keyboard hook. Unfortunately, this is rather invasive, but it's how Microsoft recommends that it be done [0]. We want to do as little as possible in the hook, so we only intercept a few crucial modifier keys there, while leaving other keys to the normal event processing flow. We will only install this hook if SDL_HINT_GRAB_KEYBOARD=1, which is not the default. This will reduce any compatibility concerns to just the SDL applications that explicitly ask for this behavior. We also remove the hook when the grab is terminated to ensure that we're not unnecessarily staying involved in key event processing when it's not required anymore. [0]: https://docs.microsoft.com/en-us/windows/win32/dxtecharts/disabling-shortcut-keys-in-games
01a2f276	2021-01-04T01:23:50	consistently use TEXT() macro with LoadLibrary() and GetModuleHandle() cf. bug #5435.
9130f7c3	2021-01-02T10:25:38	Updated copyright for 2021
cb361896	2020-12-09T07:16:22	Fixed bug 5235 - All internal sources should include SDL_assert.h Ryan C. Gordon We should really stick this in SDL_internal.h or something so it's always available.
b9cbea35	2020-10-13T21:08:20	video: Refresh Windows display list on WM_DISPLAYCHANGE - Displays may have been added, removed or changed and all cached monitor handles are invalidated as a result. - Display events are handled in three steps: 1. Mark all currently know displays as invalid 2. Enumerate all displays, adding new ones and marking known displays as valid 3. Remove all displays still invalid after enumeration - Display connect/disconnect events are sent when displays are added or removed after initial setup
771732ed	2020-08-27T17:54:52	windows: Fix numpad arrow key scancodes with numlock off We should only perform the VK_LEFT, VK_UP, etc. mapping if none of the other special mappings apply. This allows the scancode normalization for the number pad to take place as intended.
72379ba5	2020-08-25T21:22:00	windows: Fix handling of swapped mouse buttons GetAsyncKeyState() and GetRawInputData() report the state of the physical buttons without applying the user's primary/secondary mouse button swap preference. Swap the buttons returned from these functions, so we expose a consistent view of the buttons to SDL callers. This new behavior also matches the behavior of macOS and X11 backends. See the Remarks section of the GetAsyncKeyState() function on MSDN.
44f50c64	2020-06-09T21:47:41	Fixed bug 5171 - PollEvent impacts performance in 2.0.12 On some systems, GetClipCursor() impacts performance when called frequently, so only call it every once in a while to make sure we haven't lost our capture.
488b94cb	2020-04-07T09:18:19	Don't interpret raw input messages with no mouse position This happens occasionally on touch devices when raw input is enabled
0721931f	2020-04-06T19:21:56	Avoid sending regular mouse messages for touch input
6fe6946a	2020-02-11T21:19:05	Fixed relative mode mouse events stopping if you click on the title bar
f867cebb	2020-02-11T08:36:13	Fixed bug 4709 - incorrect (not) handling of windows on-screen cursor keys Alex Denisov When using Win10 on-screen keyboard (tooltip.exe), the left and right cursor keys in it do not produce SDLK_LEFT and SDLK_RIGHT events. Windows messages generated by the on-screen keyboard, for some reason, have their scancodes set to zeroes. Here is the log from Spy++: WM_KEYDOWN nVirtKey:VK_LEFT cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:0 fUp:0 WM_KEYUP nVirtKey:VK_LEFT cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:1 fUp:1 Regular physical keyboard produces VK_LEFT (ScanCode:4B) and VK_RIGHT (ScanCode:4D) which are interpreted correctly. With on-screen keyboard, the switch statement in VKeytoScancode() does not check for VK_LEFT and VK_RIGHT, returning SDL_SCANCODE_UNKNOWN, which in turn does not get mapped to anything (because the scan codes are zeroes).
a8780c6a	2020-01-16T20:49:25	Updated copyright date for 2020
758badff	2019-10-23T08:58:52	Fixed bug 4841 - Misplaced parenthesis WIN_WindowProc / WM_ACTIVATE / ClipCursor (Thanks!)
8a394209	2019-09-05T20:47:20	SDL_windowsevents.c: remove isVistaOrNewer (not used since 8cb1dc50bb28)
cc64b369	2019-08-30T15:32:15	Allow mouse messages from Wacom pens, e.g. right click pen buttons, etc.
afb9ff95	2019-08-30T08:03:19	Fixed bug where the Steam overlay would generate an event and stop input processing for the frame.
13c4d5e7	2019-08-26T17:43:01	Fixed Windows relative mouse coordinates when capturing the mouse over RDP
d5ec735a	2019-08-01T18:22:12	Add a windowID field to SDL_TouchFingerEvent (bug #4331). This is unimplemented on some platforms and will cause compile errors when building those platform backends for now.
c37c6cbb	2019-07-31T23:37:02	use WIN_IsWindowsVistaOrGreater() from core/windows for isVistaOrNewer
e7c2cf10	2019-07-15T09:36:53	Fixed bug 4704 - SDL_HINT_ANDROID_SEPERATE_MOUSE_AND_TOUCH on Windows? superfury I notice that, somehow, when locking the mouse into place(using SDL_SetRelativeMouseMode), somehow at least the movement information gets through to both mouse movement and touch movement events? My app handles both, so when moving a touched finger accross the app(using RDP from an Android device) I see the mouse moving inside the app when it shouldn't(meaning that the touch movement is ignored properly by the app(press-location dependant) but the mouse movement is still performed due to the mouse movement events)?
7e09718d	2019-07-07T11:23:16	Ignore synthetic mouse events generated for touchscreens Windows generates fake raw mouse events for touchscreens for compatibility with legacy apps that predate touch support in Windows. We already handle touch events explicitly, so drop the synthetic events to avoid duplicates.
399df540	2019-06-11T01:14:24	windows: Drop WM_ACTIVATE when window is hidden, but only if being activated. Fixes Bugzilla #4571.
f2c8d8e9	2019-06-08T10:47:43	Fixed bug 4443 - Incorrect scan code reported for numpad 5 bplu4t2f When num lock is on, the scancode reported for numpad 5 is SDL_SCANCODE_KP_5, which is correct. However, when num lock is off, windows reports the VK_CLEAR virtual key code, which is incorrectly translated into SDL_SCANCODE_CLEAR inside of the VKeytoScancode(WPARAM vkey) function.
b45abbb2	2019-04-02T17:57:27	Bug 4576: fix warning and compile
1a4c3b57	2019-04-02T16:58:11	Bug 4576: remove touch/mouse duplication for Windows
5e13087b	2019-01-04T22:01:14	Updated copyright for 2019
5029d50e	2018-11-10T16:15:48	Add SDL_TouchDeviceType enum and SDL_GetTouchDeviceType(SDL_TouchID id). Touch device types include SDL_TOUCH_DEVICE_DIRECT (a touch screen with window-relative coordinates for touches), SDL_TOUCH_DEVICE_INDIRECT_ABSOLUTE (a trackpad-style device with absolute device coordinates), and SDL_TOUCH_DEVICE_INDIRECT_RELATIVE (a trackpad-style device with screen cursor-relative coordinates). Phone screens are an example of a direct device type. Mac trackpads are the indirect-absolute touch device type. The Apple TV remote is an indirect-relative touch device type.
4659e738	2018-11-01T12:31:45	merge fallout: Patched to compile, fixed some compiler warnings, etc.
62494a2e	2018-10-31T15:03:41	Merge SDL-ryan-batching-renderer branch to default.
b262b0eb	2018-10-22T20:50:32	Small stack allocations fall back to malloc if they're unexpectedly large.
55b24b93	2018-09-26T11:17:43	Fixed bug 4265 - SDL window falls to the bottom of the screen when dragged down and stuck there Alexei On WM_WINDOWPOSCHANGED event, WIN_UpdateClipCursor() is called. SDL_WINDOW_INPUT_FOCUS is set even when the mouse pointer is not inside the SDL window and therefore ClipCursor(&rect) is called. When dragging the window and rect.bottom=800 (i.e. the bottom edge of the screen) the SDL window is clipped to the bottom of the screen and it is not possible to move it back to the center of the screen.
a1ca8441	2018-08-26T20:37:23	Update the cursor clipping each frame, in case it was stolen by another application.
15b3794f	2018-08-26T10:34:23	Only reset the clip rect if it's currently the rect we previously clipped. This prevents us from clearing the clip rect globally when another application has set it. There's also an experimental change to regularly update the clip rect for a window defensively, in case someone else has reset it. It works well, but I don't know if it's cheap enough to call as frequently as it would be called now, and might have other undesirable side effects. Also fixed whitespace and SDL coding style
a4d0571e	2018-05-07T20:10:12	Reverted change for bug 4152 - restrict the win10 mouse bug workaround to win10 v1709 only Daniel Gibson Sorry, but it seems like Microsoft didn't fix the issue properly. I just updated my Win10 machine, it now is Version 1803, Build 17134.1 I tested with SDL2 2.0.7 (my workaround was released with 2.0.8) and still got lots of events that directly undid the prior "real" events - just like before. (See simple testcase in attachement) By default it sets SDL_HINT_MOUSE_RELATIVE_MODE_WARP - which triggered (and on my machine still triggers) the buggy behavior. You can start it with -raw, then it'll not set that hint and the events will be as expected. The easiest way to see the difference is looking at the window title, which shows accumulated X and Y values: If you just move your mouse to the right, in -raw mode the number just increases. In non-raw mode (using mouse warping) it stays around 0. I also had a WinAPI-only testcase: https://gist.github.com/DanielGibson/b5b033c67b9137f0280af9fc53352c68 It just calls SetCursorPos(320,240); on each WM_MOUSEMOVE event, and it also logs all those events to a mouseevents.log textfile. This log indeed looks a bit different since the latest Win10 update: It seems like all those events with x=320 y=240 do arrive - but only after I stopped moving the mouse - even though the cursor seems to be moved back every frame (or so). So moving the mouse to the right gives X coordinates like 330, 325, 333, 340, 330, ... and then when stopping movement I get lots of events with X coordinate 320
606c5a58	2018-05-05T10:27:53	Fixed bug 4152 - Windows 10 v1803 update seems to have fixed the jumping mouse bug (see bug #3931.)
4d78a995	2018-03-26T12:38:29	Fixed bug where an SDL window that was activated while hidden could never be shown. Test code: { SDL_Window *win = SDL_CreateWindow( "Dummy", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, 128, 128, SDL_WINDOW_HIDDEN ); SDL_SysWMinfo info; SDL_VERSION( &info.version ); SDL_GetWindowWMInfo( win, &info ); SetActiveWindow( info.info.win.window ); { DWORD then = SDL_GetTicks(); while ( ( SDL_GetTicks() - then ) < 3000 ) { SDL_Event evt; SDL_PollEvent( &evt ); } SDL_ShowWindow( win ); then = SDL_GetTicks(); while ( ( SDL_GetTicks() - then ) < 3000 ) { SDL_Event evt; SDL_PollEvent( &evt ); } } SDL_DestroyWindow( win ); }
5abd7d16	2018-02-13T22:58:20	Don't attempt WM_NCCALCSIZE adjustment when in fullscreen window transition
40b27fd5	2018-02-12T17:00:00	revert the recent typecast assignment changes (see bug #4079) also change the void* typedefs for the two vulkan function pointers added in vulkan_internal.h into generic function pointer typedefs.
7b50aee9	2018-02-08T18:07:14	Fixed min/max window size handling for borderless resizable windows
90e72bf4	2018-01-30T18:08:34	Fixed ISO C99 compatibility SDL now builds with gcc 7.2 with the following command line options: -Wall -pedantic-errors -Wno-deprecated-declarations -Wno-overlength-strings --std=c99
e3cc5b2c	2018-01-03T10:03:25	Updated copyright for 2018
1b16618b	2017-12-11T11:47:52	Fixed Windows gcc build
ab06f570	2017-12-10T09:17:33	Workaround for bug 3931 - spurious SDL_MOUSEMOTION events with SDL_HINT_MOUSE_RELATIVE_MODE_WARP 1 since Windows 10 Fall Creators update 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() (https://msdn.microsoft.com/en-us/library/windows/hardware/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.
25df5a5a	2017-11-28T18:31:18	Non-resizable windows need to have their window rect set to the client rect
54685787	2017-09-26T15:07:35	Fixed bug 3847 - Hit Test x coordinate wrong on secondary monitor Robert Turner SDL_windowsevents.c contains code to retrieve the x and y coordinate for a requested hit test. It does this as follows: POINT winpoint = { (int) LOWORD(lParam), (int) HIWORD(lParam) }; LOWORD(lParam) does not correctly mask off high bits that are set if the point is on a second (or third, etc.) monitor. This effectively offsets the x-coordinate by a large value. MSDN documentation suggests that LOWORD() and HIWORD() are the wrong macros for the task, instead suggesting we should be doing something like the following: POINT winpoint = { GET_X_LPARAM(lParam), GET_Y_LPARAM(lParam) }; Testing this change on my Windows 10 machine with 2 monitors gives the correct results.
3176a7f5	2017-09-22T07:11:36	sdl - Fixing rendering borderless window. Need to force windows to send a WM_NCCALCSIZE then return 0 for non-client area size. - Adding WS_CAPTION \| WS_SYSMENU \| WS_MINIMIZEBOX to borderless windows, for reasons noted in comments. - Fix SetupWindowData() setting SDL_WINDOW_BORDERLESS. This was being cleared at window creation, causing hanlding for the first WM_NCCALCSIZE message to fail
a4cfa936	2017-08-14T21:28:04	Fixed bug 2293 - Precise scrolling events Martijn Courteaux I implemented precise scrolling events. I have been through all the folders in /src/video/[platform] to implement where possible. This works on OS X, but I can't speak for others. Build farm will figure that out, I guess. I think this patch should introduce precise scrolling on OS X, Wayland, Mir, Windows, Android, Nacl, Windows RT. The way I provide precise scrolling events is by adding two float fields to the SDL_MouseWheelScrollEvent datastructure, called "preciseX" and "preciseY". The old integer fields "x" and "y" are still present. The idea is that every platform specific code normalises the scroll amounts and forwards them to the SDL_SendMouseWheel function. It is this function that will now accumulate these (using a static variable, as I have seen how it was implemented in the Windows specific code) and once we hit a unit size, set the traditional integer "x" and "y" fields. I believe this is pretty solid way of doing it, although I'm not the expert here. There is also a fix in the patch for a typo recently introduced, that might need to be taken away by the time anybody merges this in. There is also a file in Nacl which I have stripped a horrible amount of trailing whitespaces. (Leave that part out if you want).
c87e1d52	2017-08-13T14:15:52	Fixed bug 2841 - Hint to set resource id for window icon Alexey Seems to be a missing functionality. I want to set an icon from RC file. I cant pass MAKEINTRESOURCE(X) string to SDL_RegisterApp() cause string returned by MAKEINTRESOURCE string is not actually a string and SDL_strlen will crash. Moreover LoadImage seems to be loading wrong icon size. LoadIcon seems to be fine.
47c2c7d5	2017-08-12T12:56:28	Cleaned up WindowsScanCodeToSDLScanCode() so VKeytoScancode() always takes precedence for the keys it handles and the rest of the logic is easier to read.
843293be	2017-08-09T20:26:16	Fixed bug 3701 - WM_TOUCH message may cause calls to null if touch functions are not properly loaded Simon Hug When WIN_WindowProc processes the WM_TOUCH message, it doesn't check if the touch functions have been properly loaded and may call a NULL pointer. It's probably an extremely rare case, but here's a patch that adds some checks anyway.
34769abd	2017-06-03T09:13:08	prefer virtual keycodes over scancodes for extended keys
77240762	2017-05-16T17:48:57	Fixed restoring a window that was maximized then minimized, then restored.
444c47a1	2017-04-29T22:50:35	windows: Changed six internal functions to be static.
52e9c42d	2017-01-28T14:35:35	Fixed Windows build
869b7fe3	2017-01-28T11:17:10	Fixed bug 3550 - No mouse move messages send while over the titlebar and windows edges Matthew Its possible to set SDL_CaptureMouse() so you continue receiving mouse input while the mouse is outside your window. This works however There is then a gap where no messages send, which is when the mouse is hovering the title bar and the window edges.
45b774e3	2017-01-01T18:33:28	Updated copyright for 2017
d5ddb3cb	2016-10-14T08:40:21	Fixed bug 3453 - First mouse button input after a drag and drop event is ignored Olav Sorensen After a drag and drop event, any following mouse button input (down/up) doesn't generate an event. Clicking any mouse button a second time generates an event like it should. Further investigation shows that the new SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH logic also causes this issue in other cases, like the first time you open the program and click the mouse.

19dee1cd

2021-10-22T06:37:20

Add SDL_GetWindowICCProfile(). (#4314) * Add SDL_GetWindowICCProfile * Add new SDL display events * Implement ICC profile change event for macOS * Implement ICC profile notification for Windows * Fix SDL_GetWindowICCProfile() for X11 * Fix compile errors

bfd2f899

2021-10-19T17:29:23

Fixed grab handling when focus changes between windows in the same application

7fb43643

2021-10-17T13:56:31

Don't process WM_INPUT when handling relative mode by warping the mouse cursor

06824b18

2021-10-17T19:50:39

Cleanup windows events after recent changes Improves clarity without any functional changes

a70a94e0

2021-10-15T18:11:19

Don't send a mouse leave event if the mouse is outside the window when gaining focus and in relative mode.

c583055a

2021-10-15T10:11:24

SDL_windowsevents.c (WIN_WindowProc): remove SAFE_AREA_X and SAFE_AREA_Y Not used since commit https://github.com/libsdl-org/SDL/commit/a1fabca162091b50d6f7dd71879d028319e09d80

a1fabca1

2021-10-14T16:52:21

Removed mouse warping for local mice and improved warp handling for mouse over RDP

5e89b3c8

2021-10-14T11:46:07

Don't need to use raw input to track the mouse during mouse capture (thanks Brick!)

0b6a8211

2021-10-12T14:08:20

Messages posted on the same tick are not new

6149e601

2021-10-13T00:03:56

remove IsWin10FCUorNewer() -- not used since commit 40ed9f75c9e1ed

311671a0

2021-10-12T23:50:02

fixed build after commit 6e356e20ad

6e356e20

2021-10-12T18:35:52

Fix mouse focus being set to null when a captured mouse cursor leaves the window.

40ed9f75

2021-10-08T10:05:27

Workaround for Windows occasionally ignoring SetCursorPos() calls Also, since we're flushing mouse motion before and including the warp, we don't need the isWin10FCUorNewer hack to simulate mouse warp motion. Fixes https://github.com/libsdl-org/SDL/issues/4339 and https://github.com/libsdl-org/SDL/issues/4165

16aeb8d0

2021-10-07T15:04:06

Guarantee that we don't dispatch any mouse motion from before or including the last mouse warp

dd95c9c8

2021-10-06T09:09:39

Moved focus click check into WIN_UpdateFocus() so we have the correct state when setting keyboard focus Fixes https://github.com/libsdl-org/SDL/issues/4817

0d541e5a

2021-10-06T00:36:27

Revert "Fixed relative mode mouse events stopping if you click on the title bar" This has been better fixed by b28ed02 or another related relative mouse mode change of @slouken in SDL 2.0.17 and as such can be reverted to reduce unneeded processing in WM_MOUSEMOVE

c542de92

2021-10-05T14:08:36

React to WM_NCACTIVATE instead of WM_SETFOCUS or WM_ACTIVATE for focus changes See https://github.com/libsdl-org/SDL/pull/4293 and https://github.com/libsdl-org/SDL/issues/4450 for details

632aca29

2021-10-01T16:17:38

Window input focus is based on WM_SETFOCUS and WM_KILLFOCUS as WM_ACTIVATE doesn't necessarily imply focus. Hopefully resolves https://github.com/libsdl-org/SDL/issues/4450 and https://github.com/libsdl-org/SDL/pull/4293

477fcf52

2021-09-24T10:49:46

Fixed whitespace

db68af80

2021-09-24T10:49:44

Reduce the likelyhood that the mouse will hover over the taskbar or toast notification while in relative mode, which causes a mouse leave event. This will still happen occasionally as the mouse is whipped around, if there is a window overlapping the game window, but it should happen less often now. This could even happen with the original code that warped the mouse every frame, so this should be a good compromise where we don't warp the mouse continously and we still keep the mouse in the safe area of the game window. Note that notifications can be any size, so the safe area may need to be adjusted or even dynamically defined via a hint.

287571fb

2021-09-22T17:40:57

Limit effect of in_title_click and focus_click_pending to only blocking cursor warping; without this all relative mouse motion was getting ignored when a window was activated via a mouse button

5d455cab

2021-09-21T18:15:11

Don't process raw input when the window is being dragged or clicked on.

0fd54f91

2021-09-21T18:15:11

Fixed using a tablet with raw input relative motion Tested with a Wacom Cintiq Pro 16"

8fee82d1

2021-09-21T18:15:09

Improve relative motion handling over RDP CR and research: @danielj

ccb06296

2021-08-19T03:15:02

SDL_windowsevents.c: fix build against older SDKs.

91a55a02

2021-08-13T23:59:39

Relative mouse motion is delivered to the window with keyboard focus This was the original intent (note SDL_UpdateWindowGrab() in SDL_OnWindowFocusGained() and SDL_OnWindowFocusLost()) and fixes a bug where relative motion unexpectedly stops if the task bar is covering the bottom of the game window and the mouse happens to move over it while relative mode is enabled. Another alternative would be to confine the mouse when relative mode is enabled, but that generates mouse motion which would need to be ignored, and it's possible for the user moving the mouse to combine with the mouse moving into the confined area so you can't easily tell whether to ignore the mouse motion. See https://github.com/libsdl-org/SDL/issues/4165 for a case where this is problematic.

4d9efcb5

2021-08-13T11:52:25

Fixed flag test for boolean correctness

b28ed028

2021-08-13T11:39:41

Don't warp the mouse for relative mode when the window doesn't have focus

cb1e20b0

2021-08-10T17:50:17

Added KMOD_SCROLL to track the scroll lock state Fixes https://github.com/libsdl-org/SDL/issues/4566

cb0fd05e

2021-08-07T22:41:54

Adding a clarifying comment in case a programmer unfamiliar with UTF-16 and UTF-32's relationship chances upon the code.

34701129

2021-08-07T20:51:49

Optimizing the implementation.

712e0d1f

2021-08-07T16:23:15

Fixing WM_CHAR event handling for Unicode characters outside the Basic Multilingual Plane.

41e1a236

2021-07-27T16:50:06

Correct the maximized size and position for borderless resizable windows This fixes bug https://github.com/libsdl-org/SDL/issues/4043

3b85e3fd

2021-07-24T15:47:11

Fixed internal Windows key state when using Windows+Space or Windows+G shortcuts This fixes bugs: https://github.com/libsdl-org/SDL/issues/4369 https://github.com/libsdl-org/SDL/issues/4500

c2e8a791

2021-06-12T16:20:47

SDL_windowsevents: add support for multiple mice

85b51e6c

2021-06-05T11:46:47

Fall back to polling normally if not operating the win32 message loop In this condition, we cannot safely wait/wake on events.

0dd7024d

2021-03-12T21:58:20

Modifies WaitEvent and WaitEventTimeout to actually wait instead of polling When possible use native os functions to make a blocking call waiting for an incoming event. Previous behavior was to continuously poll the event queue with a small delay between each poll. The blocking call uses a new optional video driver event, WaitEventTimeout, if available. It is called only if an window already shown is available. If present the window is designated using the variable wakeup_window to receive a wakeup event if needed. The WaitEventTimeout function accept a timeout parameter. If positive the call will wait for an event or return if the timeout expired without any event. If the timeout is zero it will implement a polling behavior. If the timeout is negative the function will block indefinetely waiting for an event. To let the main thread sees events sent form a different thread a "wake-up" signal is sent to the main thread if the main thread is in a blocking state. The wake-up event is sent to the designated wakeup_window if present. The wake-up event is sent only if the PushEvent call is coming from a different thread. Before sending the wake-up event the ID of the thread making the blocking call is saved using the variable blocking_thread_id and it is compared to the current thread's id to decide if the wake-up event should be sent. Two new optional video device methods are introduced: WaitEventTimeout SendWakeupEvent in addition the mutex wakeup_lock which is defined and initialized but only for the drivers supporting the methods above. If the methods are not present the system behaves as previously performing a periodic polling of the events queue. The blocking call is disabled if a joystick or sensor is detected and falls back to previous behavior.

157c3f80

2021-05-21T09:45:08

[SDL] Minimize number of system calls when handling WM_INPUT raw input messages. Details: Currently doing 4 system calls per WM_INPUT message, which can cause the thread handling the message loop to be swapped out several times: * GetProp - to get window data from the window handle * GetRawInputData - to retrieve the raw input data * 2 calls to GetMessageExtraInfo - to ignore synthetic mouse events generated for touchscreens In this change: * Replaced GetProp by iterating the list of windows maintained by SDL (with a fallback to GetProp). Note that this will affect all messages and not just WM_INPUT * only calling GetMessageExtraInfo if a touchscreen has been detected Fix for https://jira.valve.org/browse/CSGO-4855 @saml

89b62093

2021-04-01T14:17:53

Fix race condition that can lead to ENTER/LEAVE window events never firing On windows, when toggling the state of RelativeMode rapidly, there is a high chance that SDL_WINDOWEVENT_ENTER / SDL_WINDOWEVENT_LEAVE events will stop firing indefinitely. This aims to resolve that shortcoming by ensuring mouse focus state is correctly updated via WM_MOUSELEAVE events arriving via the windows event hook.

a78bce9e

2021-01-28T20:02:01

Properly handle keys already down when the hook is installed For keys that are already down when we install the keyboard hook, we need to allow the WM_KEYUP/WM_SYSKEYUP message to be processed normally. This ensures that other applications see the key up, which prevents the key from being stuck down from the perspective of other apps when our grab is released.

2793c9cf

2021-01-25T18:40:26

Fix grabbing Alt+Tab and Alt+Esc on Windows 7

141f4416

2021-01-24T03:55:04

fix build failure due to -Werror=declaration-after-statement (bug #5500)

8c921d82

2021-01-22T19:40:26

Implement keyboard grab support for Windows This is implemented via a low-level keyboard hook. Unfortunately, this is rather invasive, but it's how Microsoft recommends that it be done [0]. We want to do as little as possible in the hook, so we only intercept a few crucial modifier keys there, while leaving other keys to the normal event processing flow. We will only install this hook if SDL_HINT_GRAB_KEYBOARD=1, which is not the default. This will reduce any compatibility concerns to just the SDL applications that explicitly ask for this behavior. We also remove the hook when the grab is terminated to ensure that we're not unnecessarily staying involved in key event processing when it's not required anymore. [0]: https://docs.microsoft.com/en-us/windows/win32/dxtecharts/disabling-shortcut-keys-in-games

01a2f276

2021-01-04T01:23:50

consistently use TEXT() macro with LoadLibrary() and GetModuleHandle() cf. bug #5435.

9130f7c3

2021-01-02T10:25:38

Updated copyright for 2021

cb361896

2020-12-09T07:16:22

Fixed bug 5235 - All internal sources should include SDL_assert.h Ryan C. Gordon We should really stick this in SDL_internal.h or something so it's always available.

b9cbea35

2020-10-13T21:08:20

video: Refresh Windows display list on WM_DISPLAYCHANGE - Displays may have been added, removed or changed and all cached monitor handles are invalidated as a result. - Display events are handled in three steps: 1. Mark all currently know displays as invalid 2. Enumerate all displays, adding new ones and marking known displays as valid 3. Remove all displays still invalid after enumeration - Display connect/disconnect events are sent when displays are added or removed after initial setup

771732ed

2020-08-27T17:54:52

windows: Fix numpad arrow key scancodes with numlock off We should only perform the VK_LEFT, VK_UP, etc. mapping if none of the other special mappings apply. This allows the scancode normalization for the number pad to take place as intended.

72379ba5

2020-08-25T21:22:00

windows: Fix handling of swapped mouse buttons GetAsyncKeyState() and GetRawInputData() report the state of the physical buttons without applying the user's primary/secondary mouse button swap preference. Swap the buttons returned from these functions, so we expose a consistent view of the buttons to SDL callers. This new behavior also matches the behavior of macOS and X11 backends. See the Remarks section of the GetAsyncKeyState() function on MSDN.

44f50c64

2020-06-09T21:47:41

Fixed bug 5171 - PollEvent impacts performance in 2.0.12 On some systems, GetClipCursor() impacts performance when called frequently, so only call it every once in a while to make sure we haven't lost our capture.

488b94cb

2020-04-07T09:18:19

Don't interpret raw input messages with no mouse position This happens occasionally on touch devices when raw input is enabled

0721931f

2020-04-06T19:21:56

Avoid sending regular mouse messages for touch input

6fe6946a

2020-02-11T21:19:05

Fixed relative mode mouse events stopping if you click on the title bar

f867cebb

2020-02-11T08:36:13

Fixed bug 4709 - incorrect (not) handling of windows on-screen cursor keys Alex Denisov When using Win10 on-screen keyboard (tooltip.exe), the left and right cursor keys in it do not produce SDLK_LEFT and SDLK_RIGHT events. Windows messages generated by the on-screen keyboard, for some reason, have their scancodes set to zeroes. Here is the log from Spy++: WM_KEYDOWN nVirtKey:VK_LEFT cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:0 fUp:0 WM_KEYUP nVirtKey:VK_LEFT cRepeat:1 ScanCode:00 fExtended:0 fAltDown:0 fRepeat:1 fUp:1 Regular physical keyboard produces VK_LEFT (ScanCode:4B) and VK_RIGHT (ScanCode:4D) which are interpreted correctly. With on-screen keyboard, the switch statement in VKeytoScancode() does not check for VK_LEFT and VK_RIGHT, returning SDL_SCANCODE_UNKNOWN, which in turn does not get mapped to anything (because the scan codes are zeroes).

a8780c6a

2020-01-16T20:49:25

Updated copyright date for 2020

758badff

2019-10-23T08:58:52

Fixed bug 4841 - Misplaced parenthesis WIN_WindowProc / WM_ACTIVATE / ClipCursor (Thanks!)

8a394209

2019-09-05T20:47:20

SDL_windowsevents.c: remove isVistaOrNewer (not used since 8cb1dc50bb28)

cc64b369

2019-08-30T15:32:15

Allow mouse messages from Wacom pens, e.g. right click pen buttons, etc.

afb9ff95

2019-08-30T08:03:19

Fixed bug where the Steam overlay would generate an event and stop input processing for the frame.

13c4d5e7

2019-08-26T17:43:01

Fixed Windows relative mouse coordinates when capturing the mouse over RDP

d5ec735a

2019-08-01T18:22:12

Add a windowID field to SDL_TouchFingerEvent (bug #4331). This is unimplemented on some platforms and will cause compile errors when building those platform backends for now.

c37c6cbb

2019-07-31T23:37:02

use WIN_IsWindowsVistaOrGreater() from core/windows for isVistaOrNewer

e7c2cf10

2019-07-15T09:36:53

Fixed bug 4704 - SDL_HINT_ANDROID_SEPERATE_MOUSE_AND_TOUCH on Windows? superfury I notice that, somehow, when locking the mouse into place(using SDL_SetRelativeMouseMode), somehow at least the movement information gets through to both mouse movement and touch movement events? My app handles both, so when moving a touched finger accross the app(using RDP from an Android device) I see the mouse moving inside the app when it shouldn't(meaning that the touch movement is ignored properly by the app(press-location dependant) but the mouse movement is still performed due to the mouse movement events)?

7e09718d

2019-07-07T11:23:16

Ignore synthetic mouse events generated for touchscreens Windows generates fake raw mouse events for touchscreens for compatibility with legacy apps that predate touch support in Windows. We already handle touch events explicitly, so drop the synthetic events to avoid duplicates.

399df540

2019-06-11T01:14:24

windows: Drop WM_ACTIVATE when window is hidden, but only if being activated. Fixes Bugzilla #4571.

f2c8d8e9

2019-06-08T10:47:43

Fixed bug 4443 - Incorrect scan code reported for numpad 5 bplu4t2f When num lock is on, the scancode reported for numpad 5 is SDL_SCANCODE_KP_5, which is correct. However, when num lock is off, windows reports the VK_CLEAR virtual key code, which is incorrectly translated into SDL_SCANCODE_CLEAR inside of the VKeytoScancode(WPARAM vkey) function.

b45abbb2

2019-04-02T17:57:27

Bug 4576: fix warning and compile

1a4c3b57

2019-04-02T16:58:11

Bug 4576: remove touch/mouse duplication for Windows

5e13087b

2019-01-04T22:01:14

Updated copyright for 2019

5029d50e

2018-11-10T16:15:48

Add SDL_TouchDeviceType enum and SDL_GetTouchDeviceType(SDL_TouchID id). Touch device types include SDL_TOUCH_DEVICE_DIRECT (a touch screen with window-relative coordinates for touches), SDL_TOUCH_DEVICE_INDIRECT_ABSOLUTE (a trackpad-style device with absolute device coordinates), and SDL_TOUCH_DEVICE_INDIRECT_RELATIVE (a trackpad-style device with screen cursor-relative coordinates). Phone screens are an example of a direct device type. Mac trackpads are the indirect-absolute touch device type. The Apple TV remote is an indirect-relative touch device type.

4659e738

2018-11-01T12:31:45

merge fallout: Patched to compile, fixed some compiler warnings, etc.

62494a2e

2018-10-31T15:03:41

Merge SDL-ryan-batching-renderer branch to default.

b262b0eb

2018-10-22T20:50:32

Small stack allocations fall back to malloc if they're unexpectedly large.

55b24b93

2018-09-26T11:17:43

Fixed bug 4265 - SDL window falls to the bottom of the screen when dragged down and stuck there Alexei On WM_WINDOWPOSCHANGED event, WIN_UpdateClipCursor() is called. SDL_WINDOW_INPUT_FOCUS is set even when the mouse pointer is not inside the SDL window and therefore ClipCursor(&rect) is called. When dragging the window and rect.bottom=800 (i.e. the bottom edge of the screen) the SDL window is clipped to the bottom of the screen and it is not possible to move it back to the center of the screen.

a1ca8441

2018-08-26T20:37:23

Update the cursor clipping each frame, in case it was stolen by another application.

15b3794f

2018-08-26T10:34:23

Only reset the clip rect if it's currently the rect we previously clipped. This prevents us from clearing the clip rect globally when another application has set it. There's also an experimental change to regularly update the clip rect for a window defensively, in case someone else has reset it. It works well, but I don't know if it's cheap enough to call as frequently as it would be called now, and might have other undesirable side effects. Also fixed whitespace and SDL coding style

a4d0571e

2018-05-07T20:10:12

Reverted change for bug 4152 - restrict the win10 mouse bug workaround to win10 v1709 only Daniel Gibson Sorry, but it seems like Microsoft didn't fix the issue properly. I just updated my Win10 machine, it now is Version 1803, Build 17134.1 I tested with SDL2 2.0.7 (my workaround was released with 2.0.8) and still got lots of events that directly undid the prior "real" events - just like before. (See simple testcase in attachement) By default it sets SDL_HINT_MOUSE_RELATIVE_MODE_WARP - which triggered (and on my machine still triggers) the buggy behavior. You can start it with -raw, then it'll not set that hint and the events will be as expected. The easiest way to see the difference is looking at the window title, which shows accumulated X and Y values: If you just move your mouse to the right, in -raw mode the number just increases. In non-raw mode (using mouse warping) it stays around 0. I also had a WinAPI-only testcase: https://gist.github.com/DanielGibson/b5b033c67b9137f0280af9fc53352c68 It just calls SetCursorPos(320,240); on each WM_MOUSEMOVE event, and it also logs all those events to a mouseevents.log textfile. This log indeed looks a bit different since the latest Win10 update: It seems like all those events with x=320 y=240 do arrive - but only after I stopped moving the mouse - even though the cursor seems to be moved back every frame (or so). So moving the mouse to the right gives X coordinates like 330, 325, 333, 340, 330, ... and then when stopping movement I get lots of events with X coordinate 320

606c5a58

2018-05-05T10:27:53

Fixed bug 4152 - Windows 10 v1803 update seems to have fixed the jumping mouse bug (see bug #3931.)

4d78a995

2018-03-26T12:38:29

Fixed bug where an SDL window that was activated while hidden could never be shown. Test code: { SDL_Window *win = SDL_CreateWindow( "Dummy", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, 128, 128, SDL_WINDOW_HIDDEN ); SDL_SysWMinfo info; SDL_VERSION( &info.version ); SDL_GetWindowWMInfo( win, &info ); SetActiveWindow( info.info.win.window ); { DWORD then = SDL_GetTicks(); while ( ( SDL_GetTicks() - then ) < 3000 ) { SDL_Event evt; SDL_PollEvent( &evt ); } SDL_ShowWindow( win ); then = SDL_GetTicks(); while ( ( SDL_GetTicks() - then ) < 3000 ) { SDL_Event evt; SDL_PollEvent( &evt ); } } SDL_DestroyWindow( win ); }

5abd7d16

2018-02-13T22:58:20

Don't attempt WM_NCCALCSIZE adjustment when in fullscreen window transition

40b27fd5

2018-02-12T17:00:00

revert the recent typecast assignment changes (see bug #4079) also change the void* typedefs for the two vulkan function pointers added in vulkan_internal.h into generic function pointer typedefs.

7b50aee9

2018-02-08T18:07:14

Fixed min/max window size handling for borderless resizable windows

90e72bf4

2018-01-30T18:08:34

Fixed ISO C99 compatibility SDL now builds with gcc 7.2 with the following command line options: -Wall -pedantic-errors -Wno-deprecated-declarations -Wno-overlength-strings --std=c99

e3cc5b2c

2018-01-03T10:03:25

1b16618b

2017-12-11T11:47:52

Fixed Windows gcc build

ab06f570

2017-12-10T09:17:33

Workaround for bug 3931 - spurious SDL_MOUSEMOTION events with SDL_HINT_MOUSE_RELATIVE_MODE_WARP 1 since Windows 10 Fall Creators update 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() (https://msdn.microsoft.com/en-us/library/windows/hardware/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.

25df5a5a

2017-11-28T18:31:18

Non-resizable windows need to have their window rect set to the client rect

54685787

2017-09-26T15:07:35

Fixed bug 3847 - Hit Test x coordinate wrong on secondary monitor Robert Turner SDL_windowsevents.c contains code to retrieve the x and y coordinate for a requested hit test. It does this as follows: POINT winpoint = { (int) LOWORD(lParam), (int) HIWORD(lParam) }; LOWORD(lParam) does not correctly mask off high bits that are set if the point is on a second (or third, etc.) monitor. This effectively offsets the x-coordinate by a large value. MSDN documentation suggests that LOWORD() and HIWORD() are the wrong macros for the task, instead suggesting we should be doing something like the following: POINT winpoint = { GET_X_LPARAM(lParam), GET_Y_LPARAM(lParam) }; Testing this change on my Windows 10 machine with 2 monitors gives the correct results.

3176a7f5

2017-09-22T07:11:36

sdl - Fixing rendering borderless window. Need to force windows to send a WM_NCCALCSIZE then return 0 for non-client area size. - Adding WS_CAPTION | WS_SYSMENU | WS_MINIMIZEBOX to borderless windows, for reasons noted in comments. - Fix SetupWindowData() setting SDL_WINDOW_BORDERLESS. This was being cleared at window creation, causing hanlding for the first WM_NCCALCSIZE message to fail

a4cfa936

2017-08-14T21:28:04

Fixed bug 2293 - Precise scrolling events Martijn Courteaux I implemented precise scrolling events. I have been through all the folders in /src/video/[platform] to implement where possible. This works on OS X, but I can't speak for others. Build farm will figure that out, I guess. I think this patch should introduce precise scrolling on OS X, Wayland, Mir, Windows, Android, Nacl, Windows RT. The way I provide precise scrolling events is by adding two float fields to the SDL_MouseWheelScrollEvent datastructure, called "preciseX" and "preciseY". The old integer fields "x" and "y" are still present. The idea is that every platform specific code normalises the scroll amounts and forwards them to the SDL_SendMouseWheel function. It is this function that will now accumulate these (using a static variable, as I have seen how it was implemented in the Windows specific code) and once we hit a unit size, set the traditional integer "x" and "y" fields. I believe this is pretty solid way of doing it, although I'm not the expert here. There is also a fix in the patch for a typo recently introduced, that might need to be taken away by the time anybody merges this in. There is also a file in Nacl which I have stripped a horrible amount of trailing whitespaces. (Leave that part out if you want).

c87e1d52

2017-08-13T14:15:52

Fixed bug 2841 - Hint to set resource id for window icon Alexey Seems to be a missing functionality. I want to set an icon from RC file. I cant pass MAKEINTRESOURCE(X) string to SDL_RegisterApp() cause string returned by MAKEINTRESOURCE string is not actually a string and SDL_strlen will crash. Moreover LoadImage seems to be loading wrong icon size. LoadIcon seems to be fine.

47c2c7d5

2017-08-12T12:56:28

Cleaned up WindowsScanCodeToSDLScanCode() so VKeytoScancode() always takes precedence for the keys it handles and the rest of the logic is easier to read.

843293be

2017-08-09T20:26:16

Fixed bug 3701 - WM_TOUCH message may cause calls to null if touch functions are not properly loaded Simon Hug When WIN_WindowProc processes the WM_TOUCH message, it doesn't check if the touch functions have been properly loaded and may call a NULL pointer. It's probably an extremely rare case, but here's a patch that adds some checks anyway.

34769abd

2017-06-03T09:13:08

prefer virtual keycodes over scancodes for extended keys

77240762

2017-05-16T17:48:57

Fixed restoring a window that was maximized then minimized, then restored.

444c47a1

2017-04-29T22:50:35

windows: Changed six internal functions to be static.

52e9c42d

2017-01-28T14:35:35

Fixed Windows build

869b7fe3

2017-01-28T11:17:10

Fixed bug 3550 - No mouse move messages send while over the titlebar and windows edges Matthew Its possible to set SDL_CaptureMouse() so you continue receiving mouse input while the mouse is outside your window. This works however There is then a gap where no messages send, which is when the mouse is hovering the title bar and the window edges.

45b774e3

2017-01-01T18:33:28

d5ddb3cb

2016-10-14T08:40:21

Fixed bug 3453 - First mouse button input after a drag and drop event is ignored Olav Sorensen After a drag and drop event, any following mouse button input (down/up) doesn't generate an event. Clicking any mouse button a *second* time generates an event like it should. Further investigation shows that the new SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH logic also causes this issue in other cases, like the first time you open the program and click the mouse.

kc3-lang/SDL/src/video/windows/SDL_windowsevents.c

src/video/windows/SDL_windowsevents.c

Log