This won't get you pixel perfect values, since the exact ratio won't necessarily be whole pixel values, but it will be closer, and matches the logic in the other branch.
It's too close the 3.2.0 release for an API change like this.
If/when we re-add these, some things for consideration:
* What use cases does this enable that aren't currently possible?
* What cross-platform API guarantees do we make about the availability of these events? e.g. do we try to simulate them where raw input isn't actually available?
* How is this different from the existing relative mode, and how do we clearly explain when you want these events vs wanting relative mode?
Notes from @expikr:
First observation: the reason I originally passed denominators instead of multipliers was because some rational values cannot be exactly represented by floats (e.g 1/120) so instead let the end-developer decide how to do the dividing themselves. It was the reason why it was using split values with an integer numerator to begin with, instead of having both as floats or even just normalize it in advance.
On the other hand, passing them as multipliers might have hypothetical uses for dynamically passing end-user controlled scaling in a transparent manner without coupling? (Though in that case why not just do that as additional fields appended to `motion` structs in an API-compatible layout?)
So it’s somewhat of a philosophical judgement of what this API of optional availability do we intend for it to present itself as:
- should it be a bit-perfect escape hatch with the absolute minimally-denominal abstraction over platform details just enough to be able to serve the full information (á la HIDPIAPI),
- or a renewed ergonomic API for splitting relative motion from cursor motion (in light of The Great Warping Purge) so that it is unburdened by legacy RelativeMode state machines, in which case it would be more appropriate to just call it `RELATIVE` instead of `RAW` and should be added alongside another new event purely for cursor events?
This alternate API stream was conceived in the context of preserving compatibility of the existing RelativeMode state machine by adding an escape hatch. So given the same context, my taste leans towards the former designation.
However, as The Great Warping Purge has made it potentially viable to do so, if I were allowed to break ABI by nuking the RelativeMode state machine entirely, I would prefer the latter designation unified as one of three separate components split from the old state machine, each independently controlled by platform-dependent availability without any state switching of a leaky melting pot:
- cursor visibility controls (if platform has cursor)
- cursor motion events (if platform has cursor)
- relative motion events (if the platform reports hardware motion)
Mouse button numbers are passed through directly, and axis values are passed through as the raw, 32-bit, wl_fixed_t 24.8 fixed-point values, which need to be divided by the denominator to convert to int/float.
This commit does the following:
- add logic in the `WM_MOUSEMOVE` case of the Window to conditionally call `WIN_UpdateClipCursor` upon receiving cursor motion if SDL is expecting the mouse to be clipped in some way (Fixes#7890)
- remove Windows-specific periodic refresh of cursor clipping and its `SDL_HINT_MOUSE_RELATIVE_CLIP_INTERVAL` hint (superceded by the above bullet point)
- streamline the processing logic within `WIN_UpdateClipCursor` for better readability of each branch, and avoid calling the Platform API until it is absolutely necessary.
- move `relative_mouse_center` field from Windows-specific per-window `SDL_WindowData` to the global `SDL_Mouse` struct, and the corresponding hint callbacks to `SDL_mouse.c` instead of `SDL_windowswindow.c`
Slave pointer devices can seemingly lag behind the master for some reason, so use the master pointer coordinates for absolute motion.
Master events are now only filtered out on the pen path.
It is not uncommon for clients to redundantly set the window size and position, either as a holdover from an SDL 1 port, when this was required, due to any window state change triggering a universal update function that sets all window state, even if unnecessary (e.g. always calling SDL_SetWindowSize(), even if the window is fullscreen), or due to the use of compatability layers. Historically, these clients expect that their behavior won't override the base window state, which is an assumption that the windowing changes in SDL 3 broke by caching size and position changes that can't be applied immediately.
This change drops size and position requests when the window is in the maximized and fullscreen states (fullscreen-desktop windows will be repositioned, but the non-fullscreen floating position will not be overwritten), which is behavior more in line with existing client assumptions, and should ease the porting process, as well as prevent annoying bugs when older software is run via sdl2-compat.
In the process of making these changes, pending window state has been moved to separate variables in the SDL_Window struct, as this fixes bugs regarding fullscreen display selection and centering windows immediately after resize on asynchronous platforms, which had issues due to pending state possibly being overwritten.
It's possible (likely!) someone could just pass a pointer returned by
SDL_GetError for one of these strings, but the message box code has to do a
ton of complicated stuff that might _also_ call SDL_SetError, so you could
end up with the string having different contents by the time you display it.
Just make a copy of the strings unconditionally at the start, so they're safe
no matter where they came from.
Fixes#10932.
Some compositors may not implement commit-timing-v1 in addition to fifo-v1, at least not immediately, and Mesa doesn't require commit-timing for FIFO behavior. The fifo-v1 protocol alone is enough for the desired behavior.
Only check for fifo-v1 to enable Wayland by default.
This can be reverted if a toolchain arrives that can handle C99 features like
variables declared in the middle of a scope, but for now we literally can't
compile SDL3 for this platform.
Fixes#11243.
Unless there are pending client requested window coordinates, such as in the case where the position is set followed by immediately by entering fullscreen, prefer the true window coordinates as sent by the window manager to select a fullscreen display.
Fixes the case where, if the window manager moves an already maximized window to another display, the window would be made fullscreen on the wrong display since the last floating coordinates would be used.
The double quotes were passed literally to the zenity arguments which
resulted in the message box displaying literal `""` when no text was
given. The empty string is more logical in this case, e.g., the empty
title results in the message box having lesser height.
When no extra buttons are passed to zenity with `--question --switch`
arguments it fails to show anything, however, SDL3 still reports
success. To handle this case, we pass an additional "OK" button.
Include SDL_kmsdrmopengles.h before SDL_kmsdrmvulkan.h, as the Vulkan header can pull in Wayland headers, which pull in EGL headers with EGL types defined as Wayland types, which causes warnings when building with strict-aliasing and LTO.
Several functions were redundantly declared in both in the general subsystem header and the GLES header, and some signatures didn't match in both locations.
Move them all to the GLES header, as the definitions are in the GLES source file.
Currently, the rawinput thread incorrectly spreads the timestamps over idle time if the poll interval is less than 100ms, and abruptly switches to lumping all accumulated inputs to happen simultaneously if it exceeds 100ms.
This means that any game which implements retroactive event handling based on timestamps will jarringly snap between the two polar opposite extremes of incorrect behaviour.
This PR replaces the arbitrary 100ms threshold with logic based on measuring the idle start and end time.
If the thread idled for more than 125000 nanoseconds, it is considered to have not had any input in its queue before it entered idle, and the events are spread over the interval between thread wake-up and pump finish, with the final input aligned to the pump finish time.
If the thread idled for less than 125000 nanoseconds, it is considered to have events entered at some point between last pump finish and thread entering sleep, and the events are spread over the full pump-to-pump interval.
If the maximum size was changed to 0 (unbounded) while a minimum was set, the sanity check ensuring that the max size isn't less than the minimum size would incorrectly cause the operation to error out.
