If a device is positively identified as an accelerometer, pointing stick
or clickpad, then we don't need to second-guess it.
In practice this does not change the result for any device in our
test data, so add some artificial records that exercise this.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In newer kernels, devices that can be positively identified as a
particular device type (for example accelerometers) get a property
bit set. Plumb this information through into the function, but don't
use it for anything just yet.
Signed-off-by: Simon McVittie <smcv@collabora.com>
udev distinguishes between ID_INPUT_KEY, a device with any keyboard keys
at all (including for example USB numeric keypads, Bluetooth headsets
with volume control buttons, and some game controllers; and
ID_INPUT_KEYBOARD, a reasonably fully-featured keyboard that you could
use for general-purpose text entry. If we do the same here, then it's
useful input to our heuristics for identifying devices: for example,
a device with ID_INPUT_KEY could reasonably be a gamepad, but a device
with ID_INPUT_KEYBOARD certainly isn't.
Resolves: https://github.com/libsdl-org/SDL/issues/7827
Signed-off-by: Simon McVittie <smcv@collabora.com>
We can't actually tell yet whether a controller has paddles, so this code isn't effective, but I'll file an upstream issue and see if we can get that resolved.
This heuristic for gamepads without a more specific mapping already
tried two incompatible conventions for handling triggers: the Linux
Gamepad Specification uses hat switch 2 for the triggers (for whatever
reason), but the de facto standard set by the drivers for older Xbox
and Playstation controllers represents each trigger as the Z-axis of
the nearest analog stick.
Android documentation encourages Bluetooth gamepad manufacturers to use
a third incompatible convention where the left and right triggers are
represented as the brake and gas pedals of a driving simulator
controller. The Android convention also changes the representation of
the right stick: instead of using X and Y rotation as a second pair
of axes, Android uses Z position as a second horizontal axis, and
Z rotation as a second vertical axis.
Try to cope gracefully with all of these. This will hopefully resolve
the issue described in #5406 (when using unpatched kernels).
Signed-off-by: Simon McVittie <smcv@collabora.com>
The bitfield `mapped` has two different sets of meanings, depending
whether we're setting up the triggers or the d-pad. Represent them
as symbolic constants rather than opaque integers.
Signed-off-by: Simon McVittie <smcv@collabora.com>
This prevents the case where the mouse might be at the edge of the
window when enabling relative mode, which confuses macOS, at it
might believe the user is attempting to resize the window.
Fixes#6994.
(cherry picked from commit 2afb49ba9a)
This fixes the serial number for Nintendo Switch Pro, which is queried from the hardware in device initialization, and was later clobbered by the USB string which isn't correct.
Hiding a window and then clearing the minimized, maximized, fullscreen, or grabbed flags wouldn't result in the new state being applied to the window when shown, as the pending flags would always be zero, resulting in the flag application function never being entered. Calling SDL_RestoreWindow() didn't result in the minimized or maximized state being cleared on the hidden window either.
Save the current window flags to the pending flags when hiding a window, and universally apply the pending flags when the window is shown again to ensure that all state that was set or cleared when the window was hidden is applied. Any pending flags that match the existing window flags will be automatically deduplicated by the corresponding functions.
Alt-Enter will go from the current state to fullscreen desktop, or if already there, will leave fullscreen mode.
Ctrl-Enter will go from the current state to exclusive fullscreen mode, or if already there, will leave fullscreen mode.
