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
The Linux kernel exposes motion sensors of Nintendo Switch and Playstation
controllers as a separate gamecontroller device.
However, using those is currently not supported by SDL. Instead SDL
relies on its own raw HID based drivers.
In case of the Steam Deck (currently unsupported by SDL hidraw),
this can be a problem because the kernel driver has a quirk that hides
the gamepad device as soon as it is opened in hidraw mode.
Thus, non-SDL games that use the kernel gamecontroller API may break when
using SDL based mappers like antimicrox, e.g. for adding gyroscope support.
Additionally, supporting the kernel way of gamepad sensors would reduce
duplicated driver work in the long run when more and more controllers have
sensors.
Are there currently any plans for supporting this?
If not, where would be a good point to start implementing this?
As far as I have seen, the simplified implementation steps would be:
Match the main gamepad device with the motion sensors device.
This should be possible via some kernel API since both devices
have the same parent HID device in the kernel.
Register available sensors to SDL.
Open both devices, read events from them and dispatch them through SDL.
This is how it currently looks with the evtest tool for Nintendo Switch and Playstation 5 controllers:
$ evtest
No device specified, trying to scan all of /dev/input/event*
Not running as root, no devices may be available.
Available devices:
/dev/input/event22: Sony Interactive Entertainment Wireless Controller Motion Sensors
/dev/input/event23: Sony Interactive Entertainment Wireless Controller Touchpad
/dev/input/event3: Sony Interactive Entertainment Wireless Controller
Select the device event number [0-23]:
$ evtest
No device specified, trying to scan all of /dev/input/event*
Not running as root, no devices may be available.
Available devices:
/dev/input/event22: Nintendo Switch Pro Controller IMU
/dev/input/event3: Nintendo Switch Pro Controller
Select the device event number [0-22]:
For the Steam Deck, I have an untested prototype driver here.
The text was updated successfully, but these errors were encountered:
mmmaisel
changed the title
Feature Request: Support motion sensors in SDL\_sysjoystick on Linux
Feature Request: Support motion sensors in SDL_sysjoystick on Linux
Aug 15, 2023
I would like to add another call to the SDL developers to add this! This would also allow us to use the ASUS ROG Ally gyroscope under Linux. We have successfully created an iio driver for the bmi323 6DoF chip in the Ally, and I have created a mapping from the iio accelerometer and gyro data to evdev (ABS_X, ABS_Y, and ABS_Z for the accel, and ABS_RX, ABS_RY, and ABS_RZ for the gyro). Being able to map the evdev (dev/input/eventXX) to SDL would allow this to work "natively" with a TON of things.
The Linux kernel exposes motion sensors of Nintendo Switch and Playstation
controllers as a separate gamecontroller device.
However, using those is currently not supported by SDL. Instead SDL
relies on its own raw HID based drivers.
In case of the Steam Deck (currently unsupported by SDL hidraw),
this can be a problem because the kernel driver has a quirk that hides
the gamepad device as soon as it is opened in hidraw mode.
Thus, non-SDL games that use the kernel gamecontroller API may break when
using SDL based mappers like antimicrox, e.g. for adding gyroscope support.
Additionally, supporting the kernel way of gamepad sensors would reduce
duplicated driver work in the long run when more and more controllers have
sensors.
Are there currently any plans for supporting this?
If not, where would be a good point to start implementing this?
As far as I have seen, the simplified implementation steps would be:
This should be possible via some kernel API since both devices
have the same parent HID device in the kernel.
This is how it currently looks with the
evtest
tool for Nintendo Switch and Playstation 5 controllers:For the Steam Deck, I have an untested prototype driver here.
The text was updated successfully, but these errors were encountered: