Linux needs UDEV rules to use hidraw for SDL2 Motion Input on Multiple Controllers

[theofficialgman]

Current Behavior

use motion is greyed out on Nintendo Switch Pro Controller when the wii u gamepad input is selected

Expected Behavior

expect that use motion is available. see #1097 (comment) for fix

Steps to Reproduce

use latest appimage with nintendo switch pro controller. attempt to use SDL input and select use motion but it is greyed out

System Info (Optional)

No response

Emulation Settings (Optional)

No response

Logs (Optional)

No response

[theofficialgman]

same issue on flatpak

[Squall-Leonhart]

insufficient information to act on or investigate.

What controller is this.
what linux distribution and version

Your github profile tells me you should know better than to post such a vague and unactionable issue.

[theofficialgman]

What controller is this.

Controller name already provided twice. To reiterate, it's an official Nintendo switch pro controller.

what linux distribution and version

Also already partially provided. Flatpak distribution and appimage on Kubuntu Mantic 23.10.
I tested the appimages on another system today on Kubuntu Noble 24.04 development and do not have this issue.

Your github profile tells me you should know better than to post such a vague and unactionable issue.

I typically don't provide repetitive and extra irrelevant information. At the time it appeared that distro was likey irrelevant as long as hid-nintendo driver was being used from the kernel as sdl is provided in the appimage statically linked in the main binary.

[Squall-Leonhart]

6.5.0.25.25 has a proposed(and accepted) fix for switch pro controller issues.

[theofficialgman]

I looked into this. it appears that one system is in the input group (the one that works) and the other is not. the system with the user in the input group can read all /dev/input/ nodes without root. the one that isn't cannot and can only read the device node for Nintendo Switch Pro Controller and not Nintendo Switch Pro Controller IMU because only the former has extended permissions for my user (getfacl shows this).

[Squall-Leonhart]

Then this SDL issue explains whats up libsdl-org/SDL#8125

[Squall-Leonhart]

Actually, apologies but its this one libsdl-org/SDL#6478

The current dkms-nintendo driver only supplies the motion data as a dev/input/event

[theofficialgman]

Then this SDL issue explains whats up libsdl-org/SDL#8125
Actually, apologies but its this one libsdl-org/SDL#6478

no and no. the problem is not that it is exposed separated. that is solved in SDL2 years ago now (see the second issue PR close reason). the problem is that Nintendo Switch Pro Controller IMU doesn't have extended permissions to be read by my user without input group access.

[Squall-Leonhart]

libsdl-org/SDL#7697 was first added to SDL 3.0 to partially (not fully) mitigate
the udev rule with read access is still required to get the sensor.

libsdl-org/SDL#8336 backports the change to SDL 2.30 which has only just come out, should in part correct this issue and #753.

[theofficialgman]

libsdl-org/SDL#7697 was first added to SDL 3.0 to partially (not fully) mitigate the udev rule with read access is still required to get the sensor.

libsdl-org/SDL#8336 backports the change to SDL 2.30 which has only just come out, should in part correct this issue and #753.

I don't see what that PR changes. This already works on SDL2.28.5 (what is used in latest CEMU 2.0-65) as long as read access exists. I am not really sure why it works already since that PR is not in 2.28.5 edit: see #1097 (comment)

The PR to systemd linked within that PR (libsdl-org/SDL#7697 (comment)) is what is needed though to add uaccess so that regular users can read the IMU systemd/systemd#22860

[theofficialgman]

even after removing the user from the input group and rebooting it still works on my noble machine. it appears that on connecting the controller in CEMU the controller restarts or reconnects (the lights change). according to the PRs hidraw based input and motion should already be functioning in SDL2 and I have found that is what is being used here (instead of hid-nintendo event# inputs).

It works on my one system through HIDRAW as a side affect of having Steam installed, which installs a udev rule for hidraw access by user as part of the package

/lib/udev/rules.d/60-steam-input.rules

# Nintendo Switch Pro Controller over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="057e", ATTRS{idProduct}=="2009", MODE="0660", TAG+="uaccess"

# Nintendo Switch Pro Controller over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*057E:2009*", MODE="0660", TAG+="uaccess"

60-steam-input.rules.zip

so basically, the only way it is going to work in the current SDL2 (2.28.5) is if the user has that udev rule provided for hidraw access via user, like steam provides.

I have confirmed adding that rule (not all of steam, just the rule) to the system that previously was not working fixes it.

[theofficialgman]

testing the gyro in Nintendo Land it works but it appears to be offset by 90deg (I am looking at the ground with the controller flat, I have to hold the controller up/down to make it look forward).

Not sure if this is incorrect parsing by SDL2 of the hidraw input or incorrect parsing by Cemu.

edit: nevermind, just checked, that is just how this game was and I forgot.

[AlphaCraft9658]

This still happens with any SDL Controller on my side. The option for motion is grayed out and I have a controller with a gyro. It works elsewhere, but not here. So the udev rule doesn't fix it without modifications. Can this be fixed in Cemu or otherwise? It should work out of the box.