Some of the test data previously seen here was guessed from kernel
source code, and not all of it was correct. The following devices have
now been verified against `evemu-describe` output with Linux 6.3
(thanks to Jeremy Whiting for collecting this):
- basic Wiimote
- buttons
- 3-axis accelerometer
- infra-red sensor for Sensor Bar location (precise aim)
- Motion Plus accessory (3-axis gyroscope)
- Nunchuck accessory (joystick, 2 buttons, second 3-axis accelerometer)
- Classic Controller accessory (a complete traditional gamepad)
Signed-off-by: Simon McVittie <smcv@collabora.com>
This slightly newer device than the one from #7814 is functionally
equivalent when connected via USB. When connected via Bluetooth, it has
a different button mapping.
Thanks to Sam Lantinga.
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>
C SDLmain() thread might have started (mSDLThread.start() called)
while the SDL_Init() might not have been called yet,
and so the previous QUIT event will be discarded by SDL_Init() and app is running, not exiting.
This is reprocible by adding instrumentation code in the SDLActivity.
And hopefully, this could fix an ANR, where SDLActivity is in WAITING state (in thread.join()):
at java.lang.Thread.join (Thread.java:1519)
at org.libsdl.app.SDLActivity.onDestroy (SDLActivity.java)
while SDLThread seems to be running
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 2afb49ba9a2edc361a3b35d8e30be977a5bcc0c4)
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.
https://github.com/ValveSoftware/steam-devices/pull/34 lists several
more devices that are functionally equivalent to this one from the
point of view of their evdev metadata. Thanks to apgrc.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Also make details of PS4 gamepads (which are very similar from an evdev
point of view) more specific.
Thanks to Sam Lantinga and Jeremy Whiting for recording these.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Simon McVittie
SDL Wiki Bot
Anonymous Maarten
Sylvain
Sam Lantinga
Mathieu Eyraud
Linus Probert
Ryan C. Gordon
Ozkan Sezer