You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Buttplug currently supports rumble for XInput gamepads on Windows (including both the 360 and Xbox One/Series X|S generations). But gamepads are the vibrator almost everyone already has, so we'd also like to support Switch joycons (#151), Switch Pro Controllers, DualShock 4 and DualSense PlayStation gamepads, and BLE-capable Xbox One/Series X|S gamepads on platforms other than Windows.
I'd like to propose a DCM (device communication manager) that supports all of these and some more using SDL2 (which can be static linked) and the sdl2 wrapper crate.
SDL2 presents a gamepad API very similar to XInput, and can talk to gamepads using the following backends:
cross-platform including desktop Linux and Android:
hidapi: covers DS4/DualSense, Xbone, Switch, and generic BT/USB HID gamepads, as well as some oddballs like the Steam, Stadia, and Luna gamepads. Might support Wiimote and Wii U controllers?
macOS:
GameController.framework: DS4/DualSense, Xbone, Switch, and MFi (may provide more reliable rumble than hidapi: I've had some issues using a DS4's rumble through sdl2 that weren't present when using the same controller through the GC API directly)
Scope: very similar to the existing XInput DCM but on more platforms and supporting more than 4 connected gamepads. Would support common low-frequency and high-frequency vibration motors as well as battery level. (I might try to implement support for the extra set of trigger vibration motors on newer Xbone controllers, if I have one at home that has them.) Inputs would be ignored; anyone needing that much functionality should just be using SDL directly.
Testing: I have access to 360 (wired and wireless), Xbone, DualShock 4, DualSense, Switch joycon, Switch Pro Controller, Wiimote, Wii U Pro Controller, and Steam gamepads, as well as macOS, Windows, Linux, and iOS devices, and thus can test most interesting devices myself.
The text was updated successfully, but these errors were encountered:
Feature Description
Buttplug currently supports rumble for XInput gamepads on Windows (including both the 360 and Xbox One/Series X|S generations). But gamepads are the vibrator almost everyone already has, so we'd also like to support Switch joycons (#151), Switch Pro Controllers, DualShock 4 and DualSense PlayStation gamepads, and BLE-capable Xbox One/Series X|S gamepads on platforms other than Windows.
I'd like to propose a DCM (device communication manager) that supports all of these and some more using SDL2 (which can be static linked) and the
sdl2
wrapper crate.SDL2 presents a gamepad API very similar to XInput, and can talk to gamepads using the following backends:
hidapi
: covers DS4/DualSense, Xbone, Switch, and generic BT/USB HID gamepads, as well as some oddballs like the Steam, Stadia, and Luna gamepads. Might support Wiimote and Wii U controllers?GameController.framework
: DS4/DualSense, Xbone, Switch, and MFi (may provide more reliable rumble thanhidapi
: I've had some issues using a DS4's rumble throughsdl2
that weren't present when using the same controller through the GC API directly)ForceFeedback.framework
: generic HID gamepadsGameController.framework
Scope: very similar to the existing XInput DCM but on more platforms and supporting more than 4 connected gamepads. Would support common low-frequency and high-frequency vibration motors as well as battery level. (I might try to implement support for the extra set of trigger vibration motors on newer Xbone controllers, if I have one at home that has them.) Inputs would be ignored; anyone needing that much functionality should just be using SDL directly.
Testing: I have access to 360 (wired and wireless), Xbone, DualShock 4, DualSense, Switch joycon, Switch Pro Controller, Wiimote, Wii U Pro Controller, and Steam gamepads, as well as macOS, Windows, Linux, and iOS devices, and thus can test most interesting devices myself.
The text was updated successfully, but these errors were encountered: