udev and SDL Sensor and Touchpad #16188
Conversation
optimizations SDL touchpad support bugfixes
|
The checks failed due to the UDEV_TOUCH_SUPPORT not being defined. I'm not really sure what to do should I add a UDEV_SENSOR_SUPPORT macro for the sensor code? |
|
To make some test |
|
You need to fix the failing CI tasks |
|
Will do |
|
Linux x86 pipeline still failing. |
It seems that sensor API has been introduced in SDL version 2.0.9. And we are using SDL 2.0.4 for the CI as we are building under Xenial. |
|
Even if the build succeeds I don't want the pull request merged yet. It works adequately now for testing but to be usable I need to add a lot of options to adjust sensitivity and mapping. The problem is RN the retropad stack assumes there's only one set of sensors... safe assumption to make on mobile. Not so much with sensor enabled controllers. An example is that on the dualsense is the way it's set up by default you have to point the shoulder buttons up. Most people play games with the face buttons pointing up so it makes playing extremely unintuitive. I only made the pull request so people will be aware that I am working on it and maybe get some more testing on it. Please don't merge it until it's complete. |
|
You can tell GitHub to mark the PR as a draft, which will prevent it from being merged until you tell it that it's ready for review. |
|
I confirm DS4 is working with
If needed, you can adjust Sensivity in Settings Tab > Input > Gyroscope Sensitivity
|
|
CI Linux (i686) still fails. Is SDL_Sensor only available on specific SDL versions? Can we have a compile-time ifdefs for this? |
|
It seems there is a macro SDL_VERSION_ATLEAST so we could use |
|
I was going to say that maybe we should drop support for ancient versions of SDL2, but turns out SDL 2.0.9 released in 2018 so it isn't that old. |
I am confused the release date indicates May 24, 2022 ? |
|
Idk the tags tab says 2018. But when you click on it it says 2022. Maybe they have been pushing commits to it until then. https://github.com/libsdl-org/SDL/tags?after=release-2.0.18 Edit: I found https://www.phoronix.com/news/SDL-2.0.9-Released confirming it's from 2018. |
|
So someone on discord told me I should open the pull request at this state without the menu options. And then either future me or someone who knows their way around the menu code can implement it. Right now it's functional in both udev and SDL but the axes aren't where the software expects them. So in Kirby: Tilt N Tumble for example requires you to hold the dualshock horizontally when the game boots and tilt backwards to move forwards. However it does work and there are even menu options to adjust sensitivity and select which sensor device you want to use so I think it's adequate. |
|
the axes aren't where the software expects them I am working on extending remote retropad with sensor test display, and have found something similar in the only platform that I can test right now, Android. Will try to check again and see if it matches the udev behavior described above. Also, since sensor input is part of the input driver (as opposed to the joypad driver), one will not be able to change the input driver to udev/sdl in a Linux desktop environment, since video context driver will force it to be x/wayland. Probably joypad driver stack could be extended to have sensor capabilities, and input driver could have the option to let the joystick driver handle it in cases where it is reasonable. |
I have spoken about the issue at length. I have tried giving the user the ability to change the axis mappings but the menu code is a superfund site.
Well it works fine within Mate as long as you set your gamepad permissions right. I would love a way to set a distinct input driver for the joypad and keyboard/mouse because I really don't feel comfortable exposing the udev device of my keyboard to non-root apps because I use this computer for things other than Gaming. But that would require, you guessed it, changing menu code. |
|
I correct myself: x11 context + udev works, other combinations probably not. That game starts with instruction to hold the device flat, on Android it is consistent with that (i.e. no need to hold the phone upright), but will not adjust if the phone is rotated to landscape, which is an interesting challenge, I can not think of an interface how the core would be aware of that (except via the sensors themselves). |
The same way everything else is mapped. You give the user gamepad mapping files. That's what the RetroPad abstraction is for. I just need help to actually implement it. |
|
I'm excited to discover this pull request and eager to see it continue to be developed and merged. No longer is the ideal controller an XBOX 360 controller. SDL has great support now for more complex HID devices. Citra is an excellent example of an app that takes full advantage of the new SDL capabilities. Ultimately, what I'd really like to see in retroarch are sane defaults for DS4 and DS5 controllers and Joy-Cons that include gyro controls. Mobile device gyro controls should be supported and configured out of the box too. Then, I'd love to see a steam input style customization and configurtion tool that can 1) support sane default configs that are auto-detected, 2) support widely desirable community custom configurations per platform that normalize input to an extended Analog+gyro retropad 3) provide ability to use a GUI mapping tool to create and save multiple custom control configurations including gyro and button/input chording 4) provide a way to share community configurations 5) support global system configs, platform configs, and per-game configs Also, we need a better way to allow a system's game library to have optimal default controls that are configured differently per game in advance. For example, mapping wii controls to a DS4/DS5 and all the different combinations of wiimote / wiimote rotated / wiimote plus / wiimote plus rotated, Wiimote plus nunchuck, wii controller, gamecube controller. It should be possible for a team to define and preconfigure optimal analog+gyro retropad settings per game as defaults given common controllers like xbox, ds4, ds5. |
I mean it's pretty much ready to be merged. But nobody is merging it.
That's the thing I have trouble implementing because of issues with the menu code.
The configuration is just a simple text file you can share already.
All of these are up to the cores. And I can't think of a use for per-game configs in Retroarch considering all the games are already designed for the platform's standard input device.
Again that's up to the cores. All Retropad needs to do is act as a standard hook. IMO The Retropad abstraction wasn't very well thought out but it's too late to change it now. |
|
I confirm it is still working with DS4 udev. But for SDL2 driver it seems it did not find the sensor. I might have miss something. SDL2 log |
|
I still don't think SDL input driver will be effective under X. In any case, here are some logs from KMS+SDL (RPi 4, Ubuntu, SDL 2.26.5): The last line is repeated ad infinitum, and remote retropad shows no sign of sensor activity. With udev, things are working in my tests too, same observation about axes (controller held vertically matches the state of a phone set down on a tabletop) + accelerometer sensitivity had to be cranked up to 5.0 to get similar result as on Android, i.e. a tilt of 90 degrees will move the indicator to the end. As I remember, on Android it was according to the spec: RetroArch/libretro-common/include/libretro.h Line 4448 in 33d9def |
|
@LibretroAdmin I think it should be good to merge this feature, we confirmed it is working using udev and ds4. Thank you. |
|
@gouchi @zoltanvb I just wrote a minimal test program and it seems to be 100% an issue with SDL itself not with my code. prints "PS5 Controller 0 0 0" |
|
For information, DS4 gives with the SDL2 test program :
|
input/drivers/sdl_input.c
Outdated
| } | ||
| } | ||
| if (!gamepad && !sensor){ | ||
| RARCH_ERR("[sdl]: sdl_input_get_sensor_input recieved a " |
There was a problem hiding this comment.
There is a typo recieved should be received.
|
Hi there @oshaboy , I'm sorry that this PR has taken so long to be merged. If you could address the merge conflict we could start fasttracking this. |
No Problem. Better late then never. |
|
@LibretroAdmin I confirm, it is still working with DS4 udev driver using latest commit. So this feature should be good to be merged. Thank you. |
Description
Implemented Sensor and Touchpad Support for SDL and udev.
Related Issues
#16162
Reviewers
@gouchi @warmenhoven
Known Issues with the pull request
Everything is hardcoded and not adjustable by the user. Which causes problems if an unrelated device such as a mouse takes device 0. Also if you swap the gamepadsSDL Device selection doesn't work.Requires UDEV_TOUCH_SUPPORT to be enabled.