udev and SDL Sensor and Touchpad #16188

oshaboy · 2024-02-02T00:35:52Z

Description

Implemented Sensor and Touchpad Support for SDL and udev.

Related Issues

#16162

Reviewers

@gouchi @warmenhoven

Known Issues with the pull request

No Wiimote support yet.
~~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 gamepads~~
- ~~Only the axes are hardcoded now.~~
- ~~SDL Device selection doesn't work.~~
- ~~Axes are no longer hardcoded but they aren't saved for some reason~~
~~Requires UDEV_TOUCH_SUPPORT to be enabled.~~
Untested with multiple Dualshock 4s/Dualsenses

optimizations SDL touchpad support bugfixes

oshaboy · 2024-02-02T00:39:11Z

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?

gouchi · 2024-02-02T11:59:25Z

To make some test

git clone https://github.com/libretro/RetroArch.git
cd RetroArch
git fetch origin pull/16188/head:pr16188
git checkout pr16188
./configure && make -j$(nproc)

LibretroAdmin · 2024-02-02T17:57:58Z

You need to fix the failing CI tasks

oshaboy · 2024-02-02T18:01:10Z

Will do

LibretroAdmin · 2024-02-03T03:38:03Z

Linux x86 pipeline still failing.

gouchi · 2024-02-03T12:19:52Z

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.

oshaboy · 2024-02-03T14:52:44Z

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.

warmenhoven · 2024-02-03T15:01:25Z

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.

…nto linux_sensor

Cleanup Sensitivity settings and Sensor Retropad selection implemented including menu options

gouchi · 2024-02-03T22:42:46Z

I confirm DS4 is working with udev driver.

Enable Auxiliary Sensor Input in Settings Tab > Input.
Select correct Sensor in Settings Tab > input > RetroPad Binds > Port 1 Controls > Sensor Index

If needed, you can adjust Sensivity in Settings Tab > Input > Gyroscope Sensitivity

LibretroAdmin · 2024-02-04T00:51:30Z

CI Linux (i686) still fails. Is SDL_Sensor only available on specific SDL versions? Can we have a compile-time ifdefs for this?

gouchi · 2024-02-04T12:04:47Z

It seems there is a macro SDL_VERSION_ATLEAST so we could use SDL_VERSION_ATLEAST(2,0,9).

oshaboy · 2024-02-04T21:05:11Z

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.

gouchi · 2024-02-04T22:41:27Z

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 ?

Source

oshaboy · 2024-02-05T00:07:19Z

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.

oshaboy · 2025-01-19T23:57:47Z

Yalla it's done. Kirby Tilt and Tumble works flawlessly now.

oshaboy · 2025-01-20T00:14:15Z

Actually there's still a design problem

JesseTG

So far so good. However, we still need to see handlers for enabling and disabling the accelerometer and gyroscope; cores that don't need them shouldn't incur overhead in checking them. Thank you for your hard work.

libretro-common/include/libretro.h

configuration.c

JesseTG · 2025-03-13T20:22:25Z

configuration.h

+unsigned input_config_parse_sensor(
+      unsigned id,
+      char *s,
+      void *conf_data);


Is there a reason this parameter is a void* despite not being used for any kind of polymorphism?

It's necessary for the API.

Are you sure? I'm searching for uses of it but I don't see any that would need it.

IDK all other functions that take a config_file_t pass it as a void *. If you want to refactor that that's on you. I am just following Chesterton's Fence principle.

Fair enough.

JesseTG · 2025-03-13T20:23:28Z

configuration.h

-
+unsigned input_config_parse_sensor(
+      unsigned id,
+      char *s,


Could you make this parameter const to clarify your intent?

It shouldn't be const it uses char * s as a buffer. I might rename it to buffer instead.

s is only used with functions that take it as const. Is it possible you made a subtle mistake or typo somewhere?

Oh you're right. But all other functions such as fill_pathname_join_delim take a non const s. So I can't do it without discarding the qualifier.

cores/libretro-net-retropad/net_retropad_core.c

JesseTG · 2025-03-13T21:01:14Z

input/drivers/udev_input.c

 /* NOTE: must be in sync with enum udev_input_dev_type */
 static const char *g_dev_type_str[] =
 {
   "ID_INPUT_KEY",
   "ID_INPUT_MOUSE",
   "ID_INPUT_TOUCHPAD",
-   "ID_INPUT_TOUCHSCREEN"
+   "ID_INPUT_TOUCHSCREEN",
+   "ID_INPUT_ACCELEROMETER"


Should there be ID_INPUT_GYROSCOPE as well? Or am I misunderstanding something?

"ID_INPUT_ACCELEROMETER" is the whole sensor device according to udev

JesseTG · 2025-03-13T21:04:40Z

input/drivers/udev_input.c

+      case RETRO_SENSOR_GYROSCOPE_ENABLE:
+      case RETRO_SENSOR_ACCELEROMETER_ENABLE:


Did you forget to implement these?

There is no need to. Linux already initializes them before they become udev devices.

Isn't there overhead in polling sensors and running the callbacks? Maybe it's not big, but cores that don't use it shouldn't have to pay for it. I would prefer it if you only opened and polled the sensors that the core actually asks for.

I have never seen a core poll the sensors frivolously. So AFAIK no core "pays" for it if it isn't enabled.

But udev itself is still polling the sensors and running the callback, right?

There's already code that assumes everything will be initialized and enabled in one go in a big for loop. If I don't initialize and open the sensor retroarch won't know what sensors are even available or even if sensors are available.

Actually I might be able to rig something one moment

Nope, sorry. udev_input_add_device just does too much. And I really don't want to make this pull request have another big refactor that will take a month to write and 6 months to verify.

But udev itself is still polling the sensors and running the callback, right?

udev will keep polling the sensors regardless of if we want to or not. And the "callback" is actually a file read operation. udev_input_poll already just reads all the open file descriptors regardless of whether they are requested or not. If you want to optimize the udev input driver go ahead but I think this is beyond the scope of this pull request.

Honestly I think either way the branching to check whether the sensor was enabled or not will be more expensive than just running it unconditionally.

input/drivers/udev_input.c

JesseTG · 2025-03-13T21:08:30Z

menu/menu_setting.c

+         snprintf(name,NAME_MAX_LENGTH,
+            "tmp name sensor bind %d", j);


Was this part supposed to be temporary?

Honestly I am not sure what the "name" parameter even does.

pkg/android/phoenix-legacy/.project

JesseTG

Now that I've had time to test and review this on my Steam Deck, I've found a lot of areas that need improvement.

My feedback mostly concerns the sdl2 input driver. There are numerous oversights that need to be addressed, mostly involving error-handling and variable assignments. But once I made some quick and dirty changes to my local copy, the sdl2 input driver started working consistently! The finish line's starting to come into sight.

I don't know as much about how udev works so I haven't been able to provide as much feedback with the time I have available. I can say that the udev driver is still not working with my Switch Pro controller's sensors. However, I suspect that if you give error-handling and edge cases some more attention then you may be able to uncover some issues.

input/drivers/sdl_input.c

JesseTG · 2025-03-31T20:45:37Z

input/drivers/sdl_input.c

+      int numJoysticks=0,numTouchDevices=0,numSensors=0;
+      int i; int sensor_count=0;
+
+      SDL_InitSubSystem(SDL_INIT_GAMECONTROLLER);


A few things:

Don't forget to call SDL_QuitSubSystem(SDL_INIT_GAMECONTROLLER) when tearing down the driver. SDL_InitSubSystem increases the refcount of any initialized flag, so there has to be corresponding cleanup at the end.

Please remember to handle a failure here.

You may need to include the SDL_INIT_SENSOR flag as well.

SDL_INIT_SENSOR is in SDL3 only. SDL2 doesn't have it.

input/drivers/sdl_input.c

input/drivers/udev_input.c

oshaboy added 4 commits January 31, 2024 04:16

Added udev sensor support

5428652

Fixed segfault and added hotplug support.

606742b

Preliminary SDL Gyro Support

7775239

buncha stuff

ebe99ab

optimizations SDL touchpad support bugfixes

oshaboy added 2 commits February 2, 2024 19:30

Comments and UDEV_TOUCH_SUPPORT flag.

75b9de3

Remove C++ style comments

5fcea9b

oshaboy added 2 commits February 2, 2024 20:10

Update sdl_input.c

0277283

Removed silly printf hack and used proper facilities.

5113a52

oshaboy and others added 3 commits February 3, 2024 17:09

Menu Stuff

7dc3bdb

Merge branch 'libretro:master' into linux_sensor

7d3fcc1

Merge branch 'linux_sensor' of https://github.com/oshaboy/RetroArch i…

6fdfa1c

…nto linux_sensor

oshaboy marked this pull request as draft February 3, 2024 15:36

oshaboy added 3 commits February 3, 2024 17:36

I forgot a few files.

91613a4

Moved sensitivity adjustment to some other function

ac21e7d

Various

17a87f1

Cleanup Sensitivity settings and Sensor Retropad selection implemented including menu options

Segfault fix and macro renaming

809d53f

oshaboy marked this pull request as ready for review January 19, 2025 23:56

oshaboy added 3 commits January 20, 2025 02:00

I did not mean to remove that line

7382561

Forgot to add this check to the config file.

20e3839

Update configuration.c

08e8341

oshaboy marked this pull request as draft January 20, 2025 00:13

Minor changes

0cac7a4

oshaboy marked this pull request as ready for review January 20, 2025 02:41

Merge branch 'master' into linux_sensor

6a361e3

oshaboy requested a review from JesseTG March 4, 2025 02:40

Update menu_setting.c

5ebc362

JesseTG suggested changes Mar 13, 2025

View reviewed changes

oshaboy added 7 commits March 19, 2025 14:50

Picking some nits

0f03f4e

Made sure SDL only enables sensors when requested

a253cea

Update sdl_input.c

73da3df

Update sdl_input.c

e01f57f

Update sdl_input.c

b879025

Update sdl_input.c

121f7ea

asterisk

fd000ff

JesseTG suggested changes Mar 31, 2025

View reviewed changes

oshaboy added 9 commits April 2, 2025 20:37

This is why you test after a refactor.

b099b3c

Removed buggy microoptimizations

153e702

Update sdl_input.c

3e45a63

Update sdl_input.c

77820e6

Update udev_input.c

2becb46

More Error Handling

b800a69

Prevented Aux Devices being over max devices

7133929

I found a few bugs in initialization

4699c3a

Moar Error Handling

22dfac3

		case RETRO_SENSOR_GYROSCOPE_ENABLE:
		case RETRO_SENSOR_ACCELEROMETER_ENABLE:

		snprintf(name,NAME_MAX_LENGTH,
		"tmp name sensor bind %d", j);

udev and SDL Sensor and Touchpad #16188

Are you sure you want to change the base?

udev and SDL Sensor and Touchpad #16188

Conversation

oshaboy commented Feb 2, 2024 • edited Loading

Description

Related Issues

Reviewers

Known Issues with the pull request

oshaboy commented Feb 2, 2024 • edited Loading

gouchi commented Feb 2, 2024 • edited Loading

LibretroAdmin commented Feb 2, 2024

oshaboy commented Feb 2, 2024

LibretroAdmin commented Feb 3, 2024

gouchi commented Feb 3, 2024

oshaboy commented Feb 3, 2024

warmenhoven commented Feb 3, 2024

gouchi commented Feb 3, 2024 • edited Loading

LibretroAdmin commented Feb 4, 2024

gouchi commented Feb 4, 2024

oshaboy commented Feb 4, 2024

gouchi commented Feb 4, 2024

oshaboy commented Feb 5, 2024 • edited Loading

oshaboy commented Jan 19, 2025

oshaboy commented Jan 20, 2025

JesseTG left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oshaboy Mar 15, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oshaboy Mar 19, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

JesseTG left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

oshaboy commented Feb 2, 2024 •

edited

Loading

oshaboy commented Feb 2, 2024 •

edited

Loading

gouchi commented Feb 2, 2024 •

edited

Loading

gouchi commented Feb 3, 2024 •

edited

Loading

oshaboy commented Feb 5, 2024 •

edited

Loading

oshaboy Mar 15, 2025 •

edited

Loading

oshaboy Mar 19, 2025 •

edited

Loading