|
3c85cef4
|
2022-01-17T09:58:16
|
|
cleanup SDL_RegisterApp
- fix memory leak when RegisterClassEx fails
- set style according to the documentation
- eliminate duplicated SDL_Instance setter
|
|
d7873e65
|
2022-01-04T15:47:29
|
|
Disable tablet flicks under MS Windows.
|
|
|
53df0e66
|
2022-01-21T17:15:18
|
|
Fix the erroneous generation of mouse-down events from touch-move events.
The issue is that MS Windows synthesizes a mouse-move event in response
to touch-move events, and those mouse-move events are NOT labeled as
coming from a touch (e.g. GetMouseMessageSource() will not return
SDL_MOUSE_EVENT_SOURCE_TOUCH for those synthesized mouse-move events).
In addition, there seems to be no way to prevent this from happening;
https://gist.github.com/vbfox/1339671 claims to demonstrate a technique
to prevent it, but in my experience, it doesn't work.
Because of this, the "fallthrough" case can't test that the synthesized
mouse-move came from a touch-move, and starts erroneously pressing down
the mouse-button, leading to massive confusion in the client
application.
|
|
957c48b4
|
2022-01-07T10:58:04
|
|
Fixed detecting focus change to child dialogs
Fixes https://github.com/libsdl-org/SDL/issues/5157
|
|
|
120c76c8
|
2022-01-03T09:40:00
|
|
Updated copyright for 2022
|
|
|
ca18bf11
|
2021-12-16T12:01:18
|
|
Don't compare raw mouse button state with windows message button state
When mouse buttons are swapped, right mouse button down is the same value as raw mouse button up, and conceptually the two systems use different button masks, so never cache state between the two.
Fixes https://github.com/libsdl-org/SDL/issues/5108
|
|
715d4812
|
2021-11-29T22:43:25
|
|
windows: Fix GUI key state when grabbing the keyboard
When our keyboard grab hook is installed, GetKeyState() will return 0 for the
GUI keys even when they are pressed. This leads to spurious key up events when
holding down the GUI keys and the inability to use any key combos involving
those modifier keys.
|
|
|
942973dd
|
2021-11-28T09:27:28
|
|
Use mouse ID 0 for raw mouse events
We don't track state for each mouse individually, so we should just use the global mouse ID for all events.
Fixes https://github.com/libsdl-org/SDL/issues/5026
|
|
8a6e48d4
|
2021-11-14T04:40:50
|
|
constified SDL_RegisterApp()
|
|
3bf7994f
|
2021-09-27T14:38:12
|
|
Add and use `SDL_FALLTHROUGH` for fallthroughs
Case fallthrough warnings can be suppressed using the __fallthrough__
compiler attribute. Unfortunately, not all compilers have this
attribute, or even have __has_attribute to check if they have the
__fallthrough__ attribute. [[fallthrough]] is also available in C++17
and the next C2x, but not everyone uses C++17 or C2x.
So define the SDL_FALLTHROUGH macro to deal with those problems - if we
are using C++17 or C2x, it expands to [[fallthrough]]; else if the
compiler has __has_attribute and has the __fallthrough__ attribute, then
it expands to __attribute__((__fallthrough__)); else it expands to an
empty statement, with a /* fallthrough */ comment (it's a do {} while
(0) statement, because users of this macro need to use a semicolon,
because [[fallthrough]] and __attribute__((__fallthrough__)) require a
semicolon).
Clang before Clang 10 and GCC before GCC 7 have problems with using
__attribute__ as a sole statement and warn about a "declaration not
declaring anything", so fall back to using the /* fallthrough */ comment
if we are using those older compiler versions.
Applications using SDL are also free to use this macro (because it is
defined in begin_code.h).
All existing /* fallthrough */ comments have been replaced with this
macro. Some of them were unnecessary because they were the last case in
a switch; using SDL_FALLTHROUGH in those cases would result in a compile
error on compilers that support __fallthrough__, for having a
__attribute__((__fallthrough__)) statement that didn't immediately
precede a case label.
|
|
|
abc12a83
|
2021-11-11T15:58:44
|
|
Revert "Add and use `SDL_FALLTHROUGH` for fallthroughs"
This reverts commit 66a08aa3914a98667f212e79b4f0b9453203d656.
This causes problems with older compilers:
https://github.com/libsdl-org/SDL/pull/4791#issuecomment-966630997
|
|
|
66a08aa3
|
2021-09-27T14:38:12
|
|
Add and use `SDL_FALLTHROUGH` for fallthroughs
Case fallthrough warnings can be suppressed using the __fallthrough__
compiler attribute. Unfortunately, not all compilers have this
attribute, or even have __has_attribute to check if they have the
__fallthrough__ attribute. [[fallthrough]] is also available in C++17
and the next C2x, but not everyone uses C++17 or C2x.
So define the SDL_FALLTHROUGH macro to deal with those problems - if we
are using C++17 or C2x, it expands to [[fallthrough]]; else if the
compiler has __has_attribute and has the __fallthrough__ attribute, then
it expands to __attribute__((__fallthrough__)); else it expands to an
empty statement, with a /* fallthrough */ comment (it's a do {} while
(0) statement, because users of this macro need to use a semicolon,
because [[fallthrough]] and __attribute__((__fallthrough__)) require a
semicolon).
Applications using SDL are also free to use this macro (because it is
defined in begin_code.h).
All existing /* fallthrough */ comments have been replaced with this
macro. Some of them were unnecessary because they were the last case in
a switch; using SDL_FALLTHROUGH in those cases would result in a compile
error on compilers that support __fallthrough__, for having a
__attribute__((__fallthrough__)) statement that didn't immediately
precede a case label.
|
|
|
2248a549
|
2021-11-05T22:48:46
|
|
Update the focus in case we changed focus to a child window and then away from the application
In this case we'll get WM_KILLFOCUS when the child window is focused, but we'll retain focus on the top level window, but when we Alt-Tab away, we won't get another WM_KILLFOCUS or WM_NCACTIVATE, we get WM_ACTIVATE instead, so we need to check for focus updates in response to that as well.
|
|
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
|