-
-
Notifications
You must be signed in to change notification settings - Fork 987
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Controller doesn't work in some games #1720
Comments
Can you provide some examples of games where the controller is working and non-working? |
For example RPCS3 (PS3 emulator) |
I noticed that Auto/DS4 emulated gamepad with a Dualsense controller doesn't work in Forza Motorsport. When you push down on a face button, it will show ABXY on the interface, and as soon as you let go it switches back to keyboard keys. X360 works as it should. The issue appeared after updating to the latest Moonlight release with PS controller input support. |
I'm having similar issues with my PS5 controller. It use to be emulated as an Xbox controller but now that it's emulated as a DS4 controller, it barely works with anything. I'd much rather have the option for it to be emulated as a Xbox controller. |
Explicitly set Sunshine to use a Xbox 360 gamepad in the config UI. |
It seems this issue hasn't had any activity in the past 90 days. If it's still something you'd like addressed, please let us know by leaving a comment. Otherwise, to help keep our backlog tidy, we'll be closing this issue in 10 days. Thanks! |
This issue was closed because it has been stalled for 10 days with no activity. |
I tried the latest git build which includes 2606, but the problem wasn't fixed for me. What did fix it however was adding my user to the I did some testing and I could reproduce the virtual sunshine controller not being detected in Freds-Controller-Tester (added as a non-steam game). I also noticed that my Oculus Sensors showed up in the list when I ran Oh and, one last thing: All my controllers (including Sunshine) were always detected correctly when I enforced Proton 8.0-5 in Steam. So there must be something they changed in 9.0+. |
I don't intend to dig too deep here (not knowledgeable enough...), but maybe you could provide some more information on how to reproduce or debug this further:
Which games are/were affected? (Are there free games among them?)
Interesting. Did you by any chance check the solution steps independently? I.e. if it worked after you installed the 3rd package the first two might have been unrelated?
Did this controller test app give different results before and after your fix? How did you run it? Add it as external game/app to Steam? With Steam Input or without? What is your actual physical controller? Did you configure Sunshine to emulate a XboxOne controller or DualSense5? Going forward it'd be nice to exclusively use the newer builds. The new input library has replaced the old one, so any report (and fix!) should be based on the
What is your OS? Anything noteworthy? (non-standard kernel version, or driver PPA etc.) |
Affected games I have tested:
Unfortunately not, it was a pretty chaotic troubleshooting session because I just wanted to relax and play 😅
Yes, I can say that much. It was my test subject because it was quick to launch, and as soon as it detected the gamepad correctly all affected games were also fixed.
Add it as a non-steam game and keep all Steam Input settings default, which
I tested with both a PlayStation 4 DualShock 4 and an Xbox One controller, they showed the same behavoir in the beginning. During the troubleshooting I was focused on the DS4 controller on the client machine. By the way, an interesting bit from the logs:
It still works fine, but I thought you might want to know.
Operating System: Arch Linux Everything is installed through system (or AUR) packages, no Flatpaks. Steam is using its included runtime.
My Steam is still affected by ValveSoftware/steam-for-linux#11079, I wonder if there might be a general problem with Steam at the moment. Unfortunately, I didn't test any non-steam games. Output of
I actually re-tested with the two Oculus sensors plugged in, and the controller was still correctly detected by Freds Controller Tester. So that might not have been the problem, then. I also can't find any of my devices on that blacklist, so I think it's unlikely that that did anything either. I believe it was me adding myself to the Thank you for your interest, it's a sign of passion. I hope this helps you and others get closer to the solution. |
Thanks for the detailed feedback.
That's probably because
AUR is not supported by Sunshine. (There are reasons.) The official way is through this repo: https://github.com/LizardByte/pacman-repo
That might be it. Here are the udev rules that are installed by Sunshine: Sunshine/src_assets/linux/misc/60-sunshine.rules Lines 1 to 2 in aa2cf8e
TAG+="uaccess" instructs your OS to automatically grant the currently logged in user the necessary rights to /dev/uinput . uinput is used to emulate input devices by writing to /dev/uinput .https://www.kernel.org/doc/html/v4.14/input/uinput.html But I don't know how these events are then passed on to userspace. Probably through The open questions are then:
FWIW on my pc my main user is also a member of the I'm writing this up as I'm researching it ... Look what I've found in the original PR #2315:
I remember testing this PR quite earlier on and I followed those instructions. So that's why I'm in the |
@ABeltramo or @Hazer might be able to provide some insight on those 2-3 last comments here regarding the interplay of uinput / uhid / input group. (Is being in the |
This is most likely a permission error on As for the rest of the issue I think you are missing additional rules, take the Xbox One joypad for example: Sunshine/src/platform/linux/input/inputtino_gamepad.cpp Lines 26 to 30 in 9a82b68
It'll match this rule from the
I'm not sure about this one, I'd say it's a packager responsibility since it's distro dependent. |
Hmm... we used to add the user to the input group (you actually added that)... but it was removed here. Maybe these changes aren't compatible with the new inputtino stuff? |
Yeah, I've later learned the trick of using # PS5 DualSense (hidraw)
KERNEL=="hidraw*", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="0ce6", MODE="0660", TAG+="uaccess"
# Xbox One (uinput)
SUBSYSTEMS=="input", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="02ea", MODE="0660", TAG+="uaccess"
# Nintendo Switch (uinput)
SUBSYSTEMS=="input", ATTRS{idVendor}=="057e", ATTRS{idProduct}=="2009", MODE="0660", TAG+="uaccess" TO BE PROPERLY TESTED |
To sum up so far: adding the user to the |
Oh well, I was just about to write that same thing. :-) I'll just add those rules to my PR then? Loading |
Yeah, we overlapped 😅 |
Except that Steam provides its own rules, no? (for the emulated controllers, not for uinput/uhid) So I'll have to also move them out of the way temporarily? Or just check using e.g. gamepad-tester.com on a machine without Steam.
Ok, thanks! |
True, they should be under
or reboot. You should be able to easily check if they aren't present because you'll lose access to |
Hm, just found this, provided by systemd (on both Ubuntu and Arch): .../udev/rules.d$ grep JOY 70-uaccess.rules -C1
# joysticks
SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="?*", TAG+="uaccess" This looks like it's intended to take care of all controllers? (Which would be reasonable for a desktop system.) It probably can't hurt to add our rules but I'm not sure that I can even reproduce a situation where the emulated controllers are inaccessible. (But who knows...) |
I did some more tests on a rather fresh and basic Arch VM without Steam or any other gaming "cruft" that could add non-default udev rules. With sunshine-git (from yesterday) without any further manual modification:
If I use a build with PR #2906, DS5 also works right away since it makes sure The aforementioned systemd rules seem to do their job just fine. I tested using gamepad-tester.com in Firefox. The emulated controllers showed up using their name. The only weirdness is that all button pushes via moonlight produced button pushes in the VM except for the dpad which showed up as buttons, not as directional input. But that's probably due to the fact that the controller that I had handy is a bit of a niche controller ("Buffalo Classic USB Gamepad", SNES-layout) and somewhere there's an incorrect mapping. (Locally, i.e. in the browser on the VM host running Moonlight, gamepad-tester is showing correct directional input. Maybe Moonlight has a different/incorrect mapping file.) But input does go through and there are no permission issues except for As for the recent report by @Fell we might have to just leave it at:
(unless there are more such reports coming in of course) |
Is there an existing issue for this?
Is your issue described in the documentation?
Is your issue present in the nightly release?
Describe the Bug
In some games the controller is not being recognized (linux host) while I dont have the same issue when using Steam link. The only difference I can see:
The controller appears like this when using Sunshine:
[193895.683930] input: Microsoft X-Box 360 pad as /devices/virtual/input/input38
The controller appears like this when using Steam:
[193918.271611] input: Microsoft X-Box 360 pad 0 as /devices/virtual/input/input40
Expected Behavior
No response
Additional Context
No response
Host Operating System
Docker
Operating System Version
Debian GNU/Linux 12 (bookworm)
Architecture
64 bit
Sunshine commit or version
Sunshine version: v0.20.0.1303defb67c586447a03185d60eb20bea91a8eff
Package
Linux - flatpak
GPU Type
AMD
GPU Model
5700G
GPU Driver/Mesa Version
Mesa 23.2.1-1
Capture Method (Linux Only)
No response
Config
Apps
Relevant log output
The text was updated successfully, but these errors were encountered: