Introduce new joypad features provided by SDL3

[Nintorch]

Closes godotengine/godot-proposals#2829
Closes godotengine/godot-proposals#8519
Closes godotengine/godot-proposals#6930
Closes godotengine/godot-proposals#3799
Fixes #78805
Potentially addresses #98008
Partially addresses godotengine/godot-proposals#12087

Supersedes #88590
Supersedes #89193

Since SDL joypad driver was merged recently ( #106218 ), this PR adds support for new SDL joypad features that weren't previously possible due to older custom joypad implementations. These features include:

• Getting access to gamepad's sensors (accelerometer and gyroscope), including sensor calibration and simulated gravity sensor (because SDL doesn't support real gravity sensors);
• Setting gamepad's LED light, if supported by the gamepad;
• Getting information about controller's power and connection information;
• Getting access to gamepad's touchpad(s);
• DualSense adaptive triggers;
• Xbox rumble triggers (only available on Xbox One controllers, not to be confused with DualSense adaptive triggers).
• Getting gamepad's model type to check if it's a PS4 controller, an Xbox One controller, etc.;
• Getting joypad type (checking if it's a gamepad, arcade stick, flight stick, etc.);
• Getting the number of available buttons and axes on a controller;
• Getting the names for gamepad's button and axes names, if available (these may not work exactly as expected if the gamepad is not a first-party gamepad from PlayStation, Xbox or Nintendo because SDL cannot otherwise check what the labels on the controller are);
• Sending custom data packets to supported controllers via Input.send_joy_packet().

There are other more complex features that can be done with SDL functionality, but I decided to move them to separate PRs (see "TODO for separate PRs" section below).

There are some SDL functions that may not be necessary in Godot, so I think they need some discussion before they can be implemented (see "Features that need to be discussed whether they should be implemented or not" section below).

Roadmap and TODO

• Accelerometer/gyroscope enabling and getting
• SDL_GamepadHasSensor
• SDL_SetGamepadLED
• SDL_GetGamepadStringForAxis and SDL_GetGamepadStringForButton
• Input.get_joy_model() (because JoyType enum already exists) and Input.get_joy_scheme() (see SDL_GetGamepadType)
• SDL_GetGamepadPowerInfo
• SDL_GetGamepadSensorDataRate
• SDL_GetGamepadConnectionState
• SDL_JoystickType
• SDL_GetNumJoystickButtons, SDL_GetNumJoystickAxes
• SDL_GetJoystickVendor, SDL_GetJoystickProduct for Input.get_joy_info() (see Get joypad's vendor ID, product ID and name on Windows for XInput devices. #98861 ) Moved to Fix Input.get_joy_info() regression after the SDL input driver PR #108214
• Touchpad functions
• Dualsense adaptive triggers (see Any plans on Dualsense adaptive trigger support? libsdl-org/SDL#5125 and Xbox One Trigger Impulse via the Widnows Runtime API libsdl-org/SDL#4859 (comment) )
• • https://github.com/ValveSoftware/Proton/blob/ea07c02886cd1b1527761fb2222538fb9a92af33/lsteamclient/steamworks_sdk_157/isteamdualsense.h
• • I can't test it myself, because I don't have a Dualsense
• Xbox rumble triggers support
• Make sure Joycons work properly, including accelerometer and gyroscope
• Separate JoyScheme entry for horizontal joycons and fix the names for face buttons
• Accelerometer/gyroscope calibration methods (Input.start_joy_motion_calibration(), Input.step_joy_motion_calibration(), Input.stop_joy_motion_calibration(), Input.clear_joy_motion_calibration())
• SDL_SetJoystickPlayerIndex to set the physical joypad's player indication (LED light count for Switch and Wii controllers, LED color for PlayStation, no action for other controllers) Didn't work for my joycon controllers and my Dualshock 4, even though the method returned true
• Make all of the code thread safe, if it's not already (see bruvzg's PR)
• Input.get/set_joy_motion_calibration() to save/load calibration settings, uses Dictionary to do that
• Warn the user on Input.stop_joy_motion_calibration() if there are no/not enough calibration steps
• Input.get_joy_model_axis/button_name()
• Use is_ prefix instead of get_ for methods returning bool
• Use Color.srgb_to_linear() for set_joy_light()
• Input.get_joy_gravity() (see https://developer.android.com/reference/android/hardware/SensorEvent#values )
• Fix adaptive triggers (see https://github.com/libsdl-org/SDL/blob/f201b64ffe1380713b181a3421c7fd910c95aada/test/testgamecontroller.c#L304-L352 )
• Input.get_joy_touchpad_pressure()
• Handle SDL_ENABLED being not defined
• Linux support
• macOS support
• Add new files to the SDL update script
• Calibration: axes deadzone, not just vector length deadzone
• Add get_joy_scheme() override feature, and reflect that in get_joy_model_axis/button_name() (note for myself: I have an 8BitDo Wireless Adapter that can work in PlayStation Classic Controller mode, so at least an override for this one should exist so it actually reports as having PlayStation scheme)
• Accelerometer object's Y velocity is reversed in the test project (when the controller is moved upwards, the object should also move upwards)
• Gravity (in the engine code) is reversed on all 3 axes
• DualSense advanced haptic feedback? https://controllers.fandom.com/wiki/Sony_DualSense Output report Add support for DualSense adaptive triggers and haptic feedback godot-proposals#12087 DualSense advanced haptic feedback is audio-based, I assume DualSense is exposing this features as an audio device on Windows (Sources: https://www.pcgamingwiki.com/wiki/Controller:DualSense#:~:text=audio%2Dbased%20haptic%20feedback%20are%20natively%20supported%20(see%20support%20in%20games)%2C%20though%20the%20latter%20is%20only%20supported%20with%20a%20wired%20connection and https://www.reddit.com/r/PS5/comments/jnp8tu/heres_how_to_get_audio_haptic_feedback_with/ ), so I assume it's already possible to use in Godot (see https://docs.godotengine.org/en/stable/classes/class_audioserver.html#class-audioserver-property-output-device ), but to make it work better multiple output devices are required, so this feature essentially depends on Add ability to output sound from different buses to different physical devices godot-proposals#11288
• Input.send_joy_packet() SDL_SendJoystickEffect
• Fix motion sensors not working after hotplugging (It only affected the test project because after hotplugging the motion sensors weren't being enabled)
• Fix motion sensors not working properly after recalibrating (Seems to be already been fixed somehow)
• DualSense Misc1 and PaddleX button names
• Update the example project below
• Fix Meorge's macOS issue (Done by bruvzg, thank you!)

Documentation:

• Documentation for joypad device types (SDL_JoystickType): https://learn.microsoft.com/en-us/windows/win32/xinput/xinput-and-controller-subtypes
• Sensor documentation: https://wiki.libsdl.org/SDL3/SDL_SensorType (BTW Horizontal joycons' yaw and roll axes are swapped, needs to be reported to SDL github) Just checked again, they're not
• How accelerometer's gravity is calculated: https://developer.android.com/reference/android/hardware/SensorEvent#values
• Document how to get raw accelerometer values (Input.get_joy_accelerometer() + Input.get_joy_gravity())
• Input.get_joy_model_axis/button_name() may not work exactly as expected if the gamepad is not a first-party gamepad from PlayStation, Xbox or Nintendo because SDL cannot otherwise check what the labels on the controller are
• Motion sensors examples with calibration
• SDL doesn't support motion sensors (and LED light) on platforms other than the desktop ones (they don't work well on Android and iOS and they don't work at all on Web since no hidapi support on Web)
• Fix "TODO: description"

TODO when Godot gets SDL input support for other platforms

• Check which functions work on Android
• Check which functions work on iOS
• Check which functions work on Web
• Web: trigger rumble support for SDL ( https://developer.mozilla.org/en-US/docs/Web/API/GamepadHapticActuator/effects#trigger-rumble )

TODO for separate PRs

• SDL Haptic system ( Add support for force feedback in steering wheels godot-proposals#8309 https://wiki.libsdl.org/SDL3/CategoryHaptic )
• Replace InputEvent classes boilerplate code with something more simple
• Rework Godot's hat functionality (at the moment it only supports 1 hat) (also see Hats on HOTAS are mapped as d-pad #83322 and HOTAS Problem (some axes and buttons not recognized) and godot closing on remove joy mapping (Thrustmaster TWCS Trottle) #65330 ), SDL_GetNumJoystickHats
• Input.get_pov_hat_vector() (see Add InputEventJoypadHat godot-proposals#9850 )
• SDL_GetJoystickBall, SDL_GetNumJoystickBalls
• Hat (see Add InputEventJoypadHat godot-proposals#9850 ) and ball events
• Add new hat and ball functionality to InputMap
• Proper Joycon support?
• Fix potential memory leak in Input.get_joy_name()
• Touchpad events
• Battery/power events That's not something the player can control, so no need to add these events
• Godot events for accelerometer/gyroscope (InputEventJoypadAccelerometer, InputEventJoypadGyroscope)
• Virtual joypad support (see Allow creation of arbitrary joypads godot-proposals#7071 ), SDL_AttachVirtualJoystick SDL_SetJoystickVirtualButton etc.
• Expose SDL's HIDAPI capabilities? https://wiki.libsdl.org/SDL3/CategoryHIDAPI Provide an API for HID input and output reports godot-proposals#12089
• Tray support for all platforms? https://wiki.libsdl.org/SDL3/CategoryTray

Features that need to be discussed whether they should be implemented or not

• SDL_GetJoystickSerial
• SDL_GetJoystickFirmwareVersion
• SDL_GetGamepadPath
• SDL_GetGamepadSteamHandle (for https://godotsteam.com/classes/input/ ?) Handled by Fix Input.get_joy_info() regression after the SDL input driver PR #108214

TODO 2:

• Test project on macOS doesn't recognize the joycon controllers, even though InputMap does recognize them
• Mention that people will need some sort of driver for Xbox trigger rumble to work, there's an SDL github issue where that's described (or maybe they won't need it? [Windows] Trigger rumble libsdl-org/SDL#12071 )
• 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
• Input.get_joy_accelerometer() should probably return the raw accelerometer values, while there should be another method Input.get_joy_accelerometer_motion() that's equivalent to the current functionality, I think?
• Don't rely on SDL's enums directly, we may need a function to convert SDL's enums to Godot enums (for example, so we can have PLAYSTATION_GENERIC joypad model or Steam Deck model)
• Fix rumble triggers

TODO, splitting:

• Getting access to gamepad's sensors (accelerometer and gyroscope) and simulated gravity sensor (because SDL doesn't support real gravity sensors) ( Add support for joypad motion sensors #111679 )
• including sensor calibration ( Add support for joypad motion sensors #111679 )
• Setting gamepad's LED light, if supported by the gamepad; ( Add support for setting a joypad's LED light color #111681 )
• Getting information about controller's power and connection information;
• Getting access to gamepad's touchpad(s); ( Add support for joypad touchpads #111714 )
• DualSense adaptive triggers; ( Add support for DualSense Adaptive Triggers and custom joypad data packets #111682 )
• Xbox rumble triggers (only available on Xbox One controllers, not to be confused with DualSense adaptive triggers).
• Getting gamepad's model type to check if it's a PS4 controller, an Xbox One controller, etc.;
• Getting joypad type (checking if it's a gamepad, arcade stick, flight stick, etc.);
• Getting the number of available buttons and axes on a controller;
• Getting the names for gamepad's button and axes names, if available (these may not work exactly as expected if the gamepad is not a first-party gamepad from PlayStation, Xbox or Nintendo because SDL cannot otherwise check what the labels on the controller are);
• Sending custom data packets to supported controllers via Input.send_joy_packet(). ( Add support for DualSense Adaptive Triggers and custom joypad data packets #111682 )

Here's a small project to test new joypad features:
JoypadTest.zip

[Calinou]

Supersedes #88590

Note that #88590 also implements DualSense adaptive triggers, which isn't on the roadmap of this PR currently. This could be done in a separate PR in any case, but I thought I'd mention it as SDL supports adaptive triggers.

[Nintorch]

Supersedes #88590

Note that #88590 also implements DualSense adaptive triggers, which isn't on the roadmap of this PR currently. This could be done in a separate PR in any case, but I thought I'd mention it as SDL supports adaptive triggers.

Good catch, thank you, I'll add that to the roadmap!

[Meorge]

I'm especially excited to see Joy-Con support listed here. I think those are really fun little controllers, so much so that I started making my own C++ library for interfacing with them and a Godot GDExtension based off of that - however, obviously being a GDExtension, it doesn't mesh very well with Godot's built-in APIs. Having the support be more built-in to the engine would be awesome!

I'm not sure how much overlap there is between SDL's Joy-Con support and what my library does, but if a lot of the Joy-Con-specific features don't have SDL APIs, I may be able to help on that front 😄

[Nintorch]

I made a list of features that need discussion before implementing, so if you think any of the listed features are important to have built into the engine, you can let me know!

[mubinulhaque]

Feature request for a separate PR: querying for separate keyboards and mice (SDL_GetKeyboards and SDL_GetMice respectively)

[Calinou]

Feature request for a separate PR: querying for separate keyboards and mice (SDL_GetKeyboards and SDL_GetMice respectively)

Multi-keyboard/mouse support seems subpar in SDL 3 from what I've heard, so it may not be worth the effort. This is based on what I've seen in the Perfect Dark PC port Discord (people have tried implementing it there, but quickly regretted it).

[LunaCapra]

Will the gamepad type for GameCube controllers be included? It seems to be the only one not added from SDL_GamepadType.

[Meorge]

I'm still very excited for Joy-Con support and would love to contribute where I can, but thinking about it more, I think specialized support for its features would fit better as a separate PR (if not some kind of plugin/addon). 😅

Maintainers should have more of a say in this of course, but I could see it being helpful to split this up into multiple smaller PRs so that each individual one is easier to test and verify.

That all being said, for this PR (whether it ends up being split later or not) I can certainly test its functionality on macOS. Let me know if/when you'd like me to give that a shot! 😄

[Nintorch]

Will the gamepad type for GameCube controllers be included? It seems to be the only one not added from SDL_GamepadType.

Godot is currently using the latest stable release of SDL (3.2.16), which doesn't support GameCube controllers :( https://github.com/libsdl-org/SDL/blob/c9a6709bd21750f1ad9597be21abace78c6378c9/include/SDL3/SDL_gamepad.h

[LunaCapra]

Will the gamepad type for GameCube controllers be included? It seems to be the only one not added from SDL_GamepadType.

Godot is currently using the latest stable release of SDL (3.2.16), which doesn't support GameCube controllers :( https://github.com/libsdl-org/SDL/blob/c9a6709bd21750f1ad9597be21abace78c6378c9/include/SDL3/SDL_gamepad.h

That's a shame. Maybe in the future then!

[Meorge]

I know this is still marked as a draft, so these may be things you're aware of and are planning on fixing, but just in case: I got excited and decided to pull it to test on macOS, and ran into some compilation errors.

In joypad_sdl.cpp, a few switch statements don't have default cases or otherwise handle all of the possible values:

drivers/sdl/joypad_sdl.cpp:335:10: error: enumeration values 'INVALID', 'SDL_MAX', and 'MAX' not handled in switch [-Werror,-Wswitch]
  335 |         switch (p_axis) {
      |                 ^~~~~~
drivers/sdl/joypad_sdl.cpp:335:10: note: add missing switch cases
  335 |         switch (p_axis) {
      |                 ^
  336 |                 case JoyAxis::LEFT_X:
drivers/sdl/joypad_sdl.cpp:451:10: error: enumeration values 'INVALID', 'SDL_MAX', and 'MAX' not handled in switch [-Werror,-Wswitch]
  451 |         switch (p_button) {
      |                 ^~~~~~~~
drivers/sdl/joypad_sdl.cpp:451:10: note: add missing switch cases
  451 |         switch (p_button) {
      |                 ^
  452 |                 case JoyButton::A:
2 errors generated.

If I add default cases to those switch statements, I get errors about the parameters in ScePadTriggerEffectParam not all being initialized:

[ 74%] In file included from core/input/.scu/scu_core_input.gen.cpp:1:
./core/input/input.cpp:1224:2: error: missing field 'padding' initializer [-Werror,-Wmissing-field-initializers]
 1224 |         SETUP_TRIGGER_EFFECT(SCE_PAD_TRIGGER_EFFECT_MODE_OFF);
      |         ^
./core/input/input.cpp:1213:40: note: expanded from macro 'SETUP_TRIGGER_EFFECT'
 1213 |         ScePadTriggerEffectParam effect = { 0 };                                                                                                \
      |                                               ^
[ 74%] ./core/input/input.cpp:1236:2: error: missing field 'padding' initializer [-Werror,-Wmissing-field-initializers]
 1236 |         SETUP_TRIGGER_EFFECT(SCE_PAD_TRIGGER_EFFECT_MODE_FEEDBACK);
      |         ^
./core/input/input.cpp:1213:40: note: expanded from macro 'SETUP_TRIGGER_EFFECT'
 1213 |         ScePadTriggerEffectParam effect = { 0 };                                                                                                \
[ 74%]                                               ^
./core/input/input.cpp:1257:2: error: missing field 'padding' initializer [-Werror,-Wmissing-field-initializers]
 1257 |         SETUP_TRIGGER_EFFECT(SCE_PAD_TRIGGER_EFFECT_MODE_WEAPON);
      |         ^
./core/input/input.cpp:1213:40: note: expanded from macro 'SETUP_TRIGGER_EFFECT'
 1213 |         ScePadTriggerEffectParam effect = { 0 };                                                                                                \
      |                                               ^
[ 74%] ./core/input/input.cpp:1279:2: error: missing field 'padding' initializer [-Werror,-Wmissing-field-initializers]
 1279 |         SETUP_TRIGGER_EFFECT(SCE_PAD_TRIGGER_EFFECT_MODE_VIBRATION);
      |         ^
./core/input/input.cpp:1213:40: note: expanded from macro 'SETUP_TRIGGER_EFFECT'
 1213 |         ScePadTriggerEffectParam effect = { 0 };                                                                   [ 74%]                        \
      |                                               ^
[ 74%] ./core/input/input.cpp:1291:2: error: missing field 'padding' initializer [-Werror,-Wmissing-field-initializers]
 1291 |         SETUP_TRIGGER_EFFECT(SCE_PAD_TRIGGER_EFFECT_MODE_MULTIPLE_POSITION_FEEDBACK);
      |         ^
[ 74%]  note: expanded from macro 'SETUP_TRIGGER_EFFECT'
 1213 |         ScePadTriggerEffectParam effect = { 0 };                                                                                                \
      |                                               ^
./core/input/input.cpp:1320:2: error: missing field 'padding' initializer [-Werror,-Wmissing-field-initializers]
[ 74%] E_SLOPE_FEEDBACK);GGER_EFFECT(SCE_PAD_TRIGGER_EFFECT_MOD
      |         ^
./core/input/input.cpp:1213:40: note: expanded from macro 'SETUP_TRIGGER_EFFECT'
 1213 |         ScePadTriggerEffectParam effect = { 0 };                                                                                                \
      |                                               ^
[ 74%] ./core/input/input.cpp:1337:2: error: missing field 'padding' initializer [-Werror,-Wmissing-field-initializers]
 1337 |         SETUP_TRIGGER_EFFECT(SCE_PAD_TRIGGER_EFFECT_MODE_MULTIPLE_POSITION_VIBRATION);
      |         ^
./core/input/input.cpp:1213:40: note: expanded from macro 'SETUP_TRIGGER_EFFECT'
 1213 |         ScePadTriggerEffectParam effect = { 0 };                                                                                                \
      |                                               ^
[ 77%] 7 errors generated.

[Nintorch]

I haven't tried to compile on macOS yet, but I think I fixed these 2 errors, I hope it should now compile!

[Meorge]

Thanks! It compiles now, but unfortunately I get a segmentation fault immediately upon starting Godot... I may be able to look further into that soon

---

LLDB is giving this output for the location of the segfault:

Godot Engine v4.5.beta.custom_build.3a143d442 (2025-07-02 18:50:15 UTC) - https://godotengine.org
Process 33797 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x16f5ffff8)
    frame #0: 0x000000010307d4e0 godot.macos.editor.dev.arm64`dlmalloc(bytes=80) at SDL_malloc.c:4615:52
   4612     if (bytes <= MAX_SMALL_REQUEST) {
   4613       bindex_t idx;
   4614       binmap_t smallbits;
-> 4615       nb = (bytes < MIN_REQUEST)? MIN_CHUNK_SIZE : pad_request(bytes);
   4616       idx = small_index(nb);
   4617       smallbits = gm->smallmap >> idx;
   4618
Target 0: (godot.macos.editor.dev.arm64) stopped.

The backtrace seems to give an infinite loop?

(lldb) bt
  * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=2, address=0x16f5ffff8)
  * frame #0: 0x000000010307d4e0 godot.macos.editor.dev.arm64`dlmalloc(bytes=80) at SDL_malloc.c:4615:52
    frame #1: 0x0000000103081e94 godot.macos.editor.dev.arm64`dlcalloc(n_elements=1, elem_size=80) at SDL_malloc.c:4837:9
    frame #2: 0x0000000103084554 godot.macos.editor.dev.arm64`SDL_calloc(nmemb=1, size=80) at SDL_malloc.c:6471:11
    frame #3: 0x00000001030a14e0 godot.macos.editor.dev.arm64`SDL_CreateMutex at SDL_sysmutex.c:34:26
    frame #4: 0x00000001030a1894 godot.macos.editor.dev.arm64`SDL_CreateSemaphore(initial_value=0) at SDL_syssem.c:75:23
    frame #5: 0x0000000103090bdc godot.macos.editor.dev.arm64`SDL_CreateCondition at SDL_syscond.c:58:21
    frame #6: 0x00000001030a18a0 godot.macos.editor.dev.arm64`SDL_CreateSemaphore(initial_value=0) at SDL_syssem.c:76:26
    frame #7: 0x0000000103090bdc godot.macos.editor.dev.arm64`SDL_CreateCondition at SDL_syscond.c:58:21
    frame #8: 0x00000001030a18a0 godot.macos.editor.dev.arm64`SDL_CreateSemaphore(initial_value=0) at SDL_syssem.c:76:26
    frame #9: 0x0000000103090bdc godot.macos.editor.dev.arm64`SDL_CreateCondition at SDL_syscond.c:58:21
    ...
    frame #1322: 0x00000001030a18a0 godot.macos.editor.dev.arm64`SDL_CreateSemaphore(initial_value=0) at SDL_syssem.c:76:26
    frame #1323: 0x0000000103090bdc godot.macos.editor.dev.arm64`SDL_CreateCondition at SDL_syscond.c:58:21
    frame #1324: 0x00000001030a18a0 godot.macos.editor.dev.arm64`SDL_CreateSemaphore(initial_value=0) at SDL_syssem.c:76:26
    frame #1325: 0x0000000103090bdc godot.macos.editor.dev.arm64`SDL_CreateCondition at SDL_syscond.c:58:21
    frame #1326: 0x00000001030a18a0 godot.macos.editor.dev.arm64`SDL_CreateSemaphore(initial_value=0) at SDL_syssem.c:76:26
    frame #1327: 0x0000000103090bdc godot.macos.editor.dev.arm64`SDL_CreateCondition at SDL_syscond.c:58:21
    ...

[Nintorch]

This PR should likely fix your issue: #107963
It happened to you because I haven't rebased this PR yet, I will do that once all features are ready!

EDIT: Decided to rebase now!

[Meorge]

Thanks for the rebase! With that, the editor is now building, and I'm able to run the demo project.

It looks like the instance of JoypadSDL being used by the game process doesn't receive the joystick/gamepad-added events, which causes the joypads to be registered as not attached, and thus the special methods to not work. Here's my console output with some print_line statements I added to track the state:

> godot --editor --path "/Users/malcolmanderson/Downloads/JoypadTest"
Godot Engine v4.5.beta.custom_build.898c22fd8 (2025-07-03 08:10:03 UTC) - https://godotengine.org
construct joypadsdl (FOR EDITOR)
Metal 3.2 - Forward+ - Using Device #0: Apple - Apple M4 Pro (Apple9)

joystick added event
get_sdl_joystick: p_pad_idx = 0, max is 16, attached = true
Event for joypad 0: 1619 (SDL_EVENT_GAMEPAD_ADDED)
Event for joypad 0: 1543 (SDL_EVENT_JOYSTICK_BATTERY_UPDATED)
[0]
DualSense Wireless Controller 050057564c050000e60c00001be36d04

(GAME STARTED)
Godot Engine v4.5.beta.custom_build.898c22fd8 (2025-07-03 08:10:03 UTC) - https://godotengine.org
construct joypadsdl
Metal 3.2 - Forward+ - Using Device #0: Apple - Apple M4 Pro (Apple9)

get_sdl_joystick: p_pad_idx = 0, max is 16, attached = false
ERROR: JoypadSDL::get_joypad_features: joy == nullptr
   at: get_joypad_features (drivers/sdl/joypad_sdl.cpp:584)
   GDScript backtrace (most recent call first):
       [0] _ready (res://test_2.gd:4)

Note that after GAME STARTED, a new JoypadSDL is constructed (print_line() in JoypadSDL::JoypadSDL() is run), but the SDL_EVENT_GAMEPAD_ADDED event is not caught by it, so it's not able to update its copy of the joypads array.

That's my hypothesis for what's going on at the moment, at least. I know you may still be working on putting together the core functionality for the PR, but please let me know if there's anything else I can test or results I can provide to help with the macOS support!

[Nintorch]

I'm not a Godot contributor, but looking at the patch it looks great, except SDL_error.c where the logging of errors is uncommented, and it says right over it that many errors are recoverable and would never be seen in the public api, maybe logging them in the release of godot might not be a good idea.

True, but these errors are only printed if the engine was ran with --verbose flag (see joypad_sdl.cpp, I made a custom logging function for SDL), so normally these errors won't be shown, but it would be helpful in case an SDL-related (or joystick input related) issue is reported so the users won't have to compile the engine with this fix themselves to see the SDL errors :)

[Nintorch]

Note for myself (or anyone else who's willing to test it, thanks :) ): check if #78805 is resolved by this PR or in newer 4.5 betas

[Meorge]

Testing on macOS Sequoia 15.6.1 and a Joy-Con (R), with no Joy-Con (L) connected:

• ZR is mapped to Joypad Button 18 (Xbox Paddle 3)
• R is mapped to Joypad Button 16 (Xbox Paddle 1)
• All other buttons seem to have expected mappings

For a Joy-Con (L) connected and no Joy-Con (R) connected:

• The Minus button is mapped to Joypad Button 6 (Start, Xbox Menu, Nintendo +)
• ZL is mapped to Joypad Button 19 (Xbox Paddle 4)
• L is mapped to Joypad Button 17 (Xbox Paddle 2)
• Capture is mapped to Joypad Button 5 (Guide, Sony PS, Xbox Home)
• All other buttons seem to have expected mappings

When both Joy-Con are connected:

• Joy-Con (L)'s SL is mapped to Joypad Button 17 (Xbox Paddle 2)
• Joy-Con (L)'s SR is mapped to Joypad Button 19 (Xbox Paddle 4)
• Joy-Con (R)'s SL is mapped to Joypad Button 18 (Xbox Paddle 3)
• Joy-Con (R)'s SR is mapped to Joypad Button 16 (Xbox Paddle 1)
• All other buttons seem to have expected mappings

TL;DR: every Joy-Con button is recognized 🙂

---

However, in testing this, I did find that it seems to struggle with Joy-Con controllers. The test project doesn't indicate that a controller is connected ("Gamepad connected" is unchecked, "Gamepad name" is empty, etc) although the Input Map menu does register inputs from them.

Additionally, if I connect the Joy-Cons to my computer while Godot is running, I often get an error like

ERROR: Error opening gamepad at index 3: Couldn't find mapping for device (3)
   at: process_events (drivers/sdl/joypad_sdl.cpp:144)

[Nintorch]

Thank you for testing, Meorge!

However, in testing this, I did find that it seems to struggle with Joy-Con controllers. The test project doesn't indicate that a controller is connected ("Gamepad connected" is unchecked, "Gamepad name" is empty, etc) although the Input Map menu does register inputs from them

Oh, that's interesting, I will have to look into it.

Additionally, if I connect the Joy-Cons to my computer while Godot is running, I often get an error like

I also get an error like this when I connect both joycon controllers on Windows, but after that they work just fine, the test project recognizes them too.

[Tio-Henry]

In Godot 4.5, is it still not possible to use Dualsense features?

[Nintorch]

In Godot 4.5, is it still not possible to use Dualsense features?

Dualsense features are implemented in this PR, so at the moment, no :(

[Tio-Henry]

Is there any way I can access a build with this PR?

[Nintorch]

https://docs.godotengine.org/en/4.4/contributing/workflow/testing_pull_requests.html :)

[Tio-Henry]

Oh, thank you so much, and thank you so much for your work in bringing the DualSense features to Godot, with this, it will be possible to work on various experiences for players.

[Nintorch]

You're welcome, and thank you for your kind words! ❤️ :)

[Nintorch]

Oh, thank you so much, and thank you so much for your work in bringing the DualSense features to Godot, with this, it will be possible to work on various experiences for players.

Also, may I ask if the DualSense's Adaptive Triggers work correctly with this PR? I wish I could test it myself, but I don't have a DualSense controller :(

[LoFiKari]

Oh, thank you so much, and thank you so much for your work in bringing the DualSense features to Godot, with this, it will be possible to work on various experiences for players.

Also, may I ask if the DualSense's Adaptive Triggers work correctly with this PR? I wish I could test it myself, but I don't have a DualSense controller :(

I can do that for you!

[LoFiKari]

Is there a built version of the Project?

[Nintorch]

Is there a built version of the Project?

Yes, pull requests (or Godot builds with the pull requests applied) can be tested by following the steps in this link: https://docs.godotengine.org/en/4.4/contributing/workflow/testing_pull_requests.html

[LoFiKari]

Is there a built version of the Project?

Yes, pull requests (or Godot builds with the pull requests applied) can be tested by following the steps in this link: https://docs.godotengine.org/en/4.4/contributing/workflow/testing_pull_requests.html

Is there a non-mono Linux editor?

[LoFiKari]

I can confirm, the triggers do work!

[LoFiKari]

Rumble triggers don't though

(Edit: I'm stupid, this is an Xbox feature lol, haven't tested on Xbox)

[LoFiKari]

One issue with the build: the Camera3Ds don't work from my testing

[Nintorch]

I can confirm, the triggers do work!

That's good to hear! Thank you for testing! :)

[Nintorch]

One issue with the build: the Camera3Ds don't work from my testing

That's strange, I haven't touched anything 3D related in this PR.

[LoFiKari]

One issue with the build: the Camera3Ds don't work from my testing

That's strange, I haven't touched anything 3D related in this PR.

it could be a bug transitioning my project from godot 4.4 to 4.5, ill do some more testing

(edit: its a me issue lol, ill figure it out)

[Meorge]

Testing on macOS with a DualSense controller plugged in via USB, the trigger haptics work for me! 🥳

The parameters the test project currently uses make it a bit hard to feel, but when I turn the strength up more I can definitely feel the difference in how the triggers respond.

It shouldn't block the completion/merging of this PR, but I think it could be good to include a bit more detail in the documentation about how the haptic trigger functions work, perhaps with a code example or two. (I'd love for the docs to have something like this for haptics in general, actually, but again this is getting out of scope for this PR 😅 )

[graywes]

ive tested xbox controllers. the rumble trigger button doesnt work. ive used a program to test my rumble triggers and they are functional. ive tested over usb and wireless adapter.

controller: xbox one controller (original, no bluetooth)

program used: https://github.com/araghon007/X1nput
both godot and this program are under mit license so i think you are free to take "inspiration" form it as much as you like. he's using hid requests to start the rumble effect. perhaps you could attempt detection of an xbox controller then allow transmission of hid requests for rumble

[Nintorch]

Now that I think about it, I think I can separate this big PR into several smaller PRs so it can be reviewed and merged more easily.

[AL2009man]

ive tested xbox controllers. the rumble trigger button doesnt work. ive used a program to test my rumble triggers and they are functional. ive tested over usb and wireless adapter.

controller: xbox one controller (original, no bluetooth)

program used: https://github.com/araghon007/X1nput both godot and this program are under mit license so i think you are free to take "inspiration" form it as much as you like. he's using hid requests to start the rumble effect. perhaps you could attempt detection of an xbox controller then allow transmission of hid requests for rumble

if i recall from testing on a separate project a couple of months ago: you'd need to enable one of the hints

• SDL_HINT_JOYSTICK_RAWINPUT and SDL_HINT_JOYSTICK_RAWINPUT_CORRELATE_XINPUT
• SDL_HINT_JOYSTICK_WGI
• SDL_HINT_JOYSTICK_GAMEINPUT (SDL maintainers strongly recommends this)
• ask users to download Steam's Xbox Extended Feature driver.

the RawInput method is your best bet, but it's currently broken due to a Windows Update regression (libsdl-org/SDL#13047 (comment)). Which means: the best possible route to take is to enable GameInput (but requires either slapping in a GameInput.h or built using Xbox GDK) or enabling WGI.

not exactly ideal for the Trigger Rumbles situation