Add support for joypad motion sensors

[Nintorch]

Closes godotengine/godot-proposals#2829
Partially supersedes #88590
Requires #111707 to be merged first

I decided to split my big SDL3 joypad features PR ( #107967 ) into several smaller PRs, starting with joypad motion sensors.

This PR adds the ability to get a joypad's motion sensors (accelerometer, gyroscope) data readings (and also a simulated gravity sensor from the accelerometer data). The reason the gravity sensor had to be simulated: libsdl-org/SDL#6555 (comment)
This PR also includes the methods to calibrate the motion sensors output. I'm not an expert in sensor calibration, so please let me know if this approach looks good enough :D
EDIT: If the gravity calculation proves to not be good enough, we can probably use https://github.com/JibbSmart/GamepadMotionHelpers (if it's better) instead in this PR or in a separate PR to not block this one

Gravity sensor calculation code was borrowed from here: https://developer.android.com/reference/android/hardware/SensorEvent#values

This PR was tested on Windows, but it should also work on Linux and macOS.

TODO:

• Mention that it's recommended to disable the motion sensors if they're no longer needed because it can theoretically drain the controller's battery more quickly
• InputEventJoypadGyroscope and InputEventJoypadAccelerometer (for a separate PR)
• Input.get_joy_sensor_rate()?
• Use GamepadMotionHelpers library for calibration (for a separate PR too?)
• Include the accelerometer gravity part in both calibrated and non-calibrated modes (sorry for being indecisive 😅)
• Invert the sensors axes (see also Document mobile motion sensors axes #113635 )
• Mark the has_joy_*, set_joy_*_enabled and is_joy_*_enabled as experimental (we may or may not need to only enable/disable the motion sensors together in the future, I think)

Test project (doesn't include the calibration yet):
joypad-motion-sensors.zip

[Meorge]

I'll try to test and review this on macOS soon!

I'm not a maintainer of course, but IMO it'd make sense to include the calibration methods as well. That way, this PR can function as a sort of all-encompassing "motion control API pack", if that makes sense. (Additionally/alternatively, it could be looked at from the perspective of, without being able to calibrate the sensors, how can we be confident the functions are working correctly?)

[Nintorch]

Should I try combining the calibration process methods into one Input.calibrate_joy_motion_sensors() by using a separate thread and a completion signal? I tried once, but failed. I can try again though if that means the calibration becomes more convenient :D

[Nintorch]

An event probably needs to be added for this.

(Should these events exist? Should they be made in this PR?)

[Nintorch]

Same here.

[Nintorch]

Should this PR convert the values to degrees per second for gyroscope and g-force for accelerometer? See https://github.com/JibbSmart/GamepadMotionHelpers?tab=readme-ov-file#units , which was mentioned in the proposal: godotengine/godot-proposals#2829

EDIT: I found out that Input.get_accelerometer and Input.get_gyroscope use the same units as SDL, so no need to change the units in this PR

[geowarin]

I think Steam uses SDL under the hood for Steam Input, so basically issues that are reproducible in Steam can be reported to the SDL repository, AFAIK.

Hello and thanks for your awesome work @Nintorch! As a user of a dual sense edge on linux (I'm assuming that we are rare specimens), I just wanted to chime in and say that gyros work perfectly with steam input.

I don't want to block this PR or anything, as I alluded this is a pretty niche problem, but I don't want you to jump to the wrong conclusions just in case.

I can offer my help testing the PR if you want, just tell me what you need.

[Nintorch]

I think Steam uses SDL under the hood for Steam Input, so basically issues that are reproducible in Steam can be reported to the SDL repository, AFAIK.

Hello and thanks for your awesome work @Nintorch! As a user of a dual sense edge on linux (I'm assuming that we are rare specimens), I just wanted to chime in and say that gyros work perfectly with steam input.

I don't want to block this PR or anything, as I alluded this is a pretty niche problem, but I don't want you to jump to the wrong conclusions just in case.

I can offer my help testing the PR if you want, just tell me what you need.

Hello, thank you for letting me know!
May I ask if you can test the DualSense Edge gyro with this PR and the testing project Calinou provided, please? :D

[geowarin]

I'm so sorry, I might be doing something stupid but I get gdscript errors when using the test project:

Error at (60, 5): Static function "enable_joy_gyroscope()" not found in base "GDScriptNativeClass".

[Nintorch]

Oh yeah, I've renamed these enable_joy_* functions back to set_joy_*_enabled, so now the test project will need to be modified 😅

[geowarin]

Ok good news! It works perfectly for me.

Using Arch linux + KDE.
Dualsense edge controller wired and bluetooth both work with gyro.
The led color changes as expected.

[Nintorch]

That's good to hear! :)

[geowarin]

EDIT: I just noticed that there's vector negation happening for the gyro_look variable, I think that's the reason the values are inverted:

I noticed this as well, the movement looked inverted for me until I removed the negation from line 157. I wonder why it was added? User preference or buggy controller mapping?

[Nintorch]

I removed the step_joy_motion_calibration method to make the process even easier and possibly more accurate, and I modified the way get_joy_accelerometer works, now it only returns the controller movement without the gravity value.

[Nintorch]

I should probably state in the documentation that motion sensors is an experimental feature and its usage may change in the future based on the feedback.

[Calinou]

I noticed this as well, the movement looked inverted for me until I removed the negation from line 157. I wonder why it was added? User preference or buggy controller mapping?

I needed it to be inverted in earlier PRs that added gyro support, but you can safely remove the negation now.

[Nintorch]

Although, if Input.get_joy_gyroscope is inverted compared to Input.get_gyroscope (and the accelerometer and gravity ones for that matter, but I haven't tested any of them), I should be able to revert it back.

EDIT: they really are inverted compared to mobile device's orientation methods, I will need to fix that
EDIT 2: Fixed!