Wayland previously didn't specify that the seat name preceded the capabilities, but it is now specified that the name event must always come first. Remove the 'SDL_Set<device>Name()' functions that were only added to accommodate the case of compositors sending the name after the seat capabilities, as this clarification means that they are no longer needed.
This can be toggled per-window, so use the individual window flags instead of the global toggle to selectively enable it only for the relevant window in a multi-seat scenario, as is already done with keyboard and pointer grabs.
Wayland environments can expose more than one seat for multiple collections of input devices, which can include multiple, simultaneously active, desktop pointers and keyboards with independent layouts. The Wayland input backend previously presumed that only one seat could exist, which caused broken behavior if the compositor exposed more than one, which is possible on wlroots based compositors such as Sway. This introduces support for handling multiple seats, including proper handling of dynamically added and removed seats and capabilities at run time.
The SDL Wayland input system was accreted over time, and the assumption that only one seat will ever exist resulted in state and related objects not always being tied to their most appropriate owner in a multi-seat scenario, so refactoring was required to manage several bits of state per-seat, instead of per-window or globally.
As Wayland keyboards can have per-seat layouts, fast keymap switching is required when multiplexing input from multiple seats to the global SDL keyboard device. A parameter was added to the keymap creation function to specify if the keymap lifetime should be externally managed to facilitate keymap reuse, and some layout info was moved from the global keyboard state to the keymap state to avoid unnecessarily redetermining it whenever a reused keymap is bound. This reduces the overhead of switching keymaps to setting a single pointer.
Multiple seats also means that multiple windows can have keyboard and/or mouse focus at the same time on some compositors, but this is not currently a well-handled case in SDL, and will require more work to support, if necessary.
SDL 2.0.18 added preciseX/Y to mouse wheel events, which we cannot
emulate in sdl2-compat without a mechanism to control integer position
and scroll deltas separately.
* Update SDL_mouse.c
Stop a mouseID of SDL_PEN_MOUSEID being discarded when dispatching mouse events. I'm not sure if this enough to fix the lack of SDL_PEN_MOUSEID being emitted.
* Update SDL_mouse.c
Since we test for touch input here we also test for pen input in the same way.
* Stop duplicate synthetic touch events
If SDL_HINT_PEN_MOUSE_EVENTS and SDL_HINT_MOUSE_TOUCH_EVENTS are both enabled, the pen generated synthetic mouse event will then produce a touch event without this additional check.
This requires the previous commits in order to do anything since it needs to be able to identify those pen generated mouse events.
We'll switch to the global mouse ID just once we are ready to deliver events.
This makes sure that any button events that come in for a specific mouse ID maintain that state if we switch to relative mode and start using that mouse ID for events.
Fixes https://github.com/libsdl-org/sdl2-compat/issues/263
We'll track the click count separately for each input source, and the click distance is calculated using a point on an infinite plane that is pushed around by mouse motion deltas, unclamped by the window edge.
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)
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`
The following changes do not alter any logic:
- rename x/ydelta fields to x/y_accu to better reflect what it actually is about
- coalesce the logic for modifying internal state to one spot, branch based on whether the input was a move or a warp
The following changes alter the logic:
- put the x/y_accu addition under the relative branch only, warps should not add to the accumulation buffer by any definition
- (MAIN FIX) when the destination window desires relative mode, warp events should be dropped if SDL_MOUSE_RELATIVE_WARP_MOTION is false, or have x/yrel set to zero if true
We require stdbool.h in the build environment, so we might as well use the plain bool type.
If your environment doesn't have stdbool.h, this simple replacement will suffice:
typedef signed char bool;
