@ABeltramo

To clarify which AUR package are you using?

Do you have the same issue if you use https://github.com/LizardByte/pacman-repo (beta)?

I was using this one: https://aur.archlinux.org/packages/sunshine-beta-bin.

I didn't know about the official one. Now I have installed the one you linked (and uninstalled the previous one).

The problem persist with this package too.

Btw since I have opened the online tester again I have gathered some additional info: most of the buttons are correctly recognized. Those that behave incorrectly are:

Triggers (L2/R2) - Right Stick.: these two are inverted: the triggers are recognized as the X and Y axis for the Right Stick and the Right Stick X and Y movement are recognized as L2/R2. To be more precise: L2 <--> Xaxis and R2<-->Yaxis.

XOTriangleSquare: these are rotated by one position. Example: if I press Square it is recognized as X.

Can't say anything about the buttons: L3, R3 and playstation logo. The keypress signal is there but I don't know if they are correctly recognized (no visual feedback).

Mousepad and microphone have no feedback at all in the tester on the tester but the mousepad is working without problems in the OS.

Sorry for the multiple posts.

I am doing some other tests and I have found this site: https://ds.daidr.me/ (it has a git here: https://github.com/daidr/dualsense-tester)
This site recognize the all inputs correctly.

Currently we have:
FAIL: KDE and gamepad tester
OK: steam and https://ds.daidr.me/

Thanks for all the info, I'm afraid I'll need some more 😅

To give you a bit more context, the Desktop environment (KDE) doesn't deal with joypads because compositors in Linux (X11/Wayland) don't recognise them. So, what every app/game does is to access the gamepads as USB devices directly via /dev/input and/or /dev/hidraw.

There are a few high-level libraries to do that, and the most common is SDL, which is used by Steam, Moonlight, and Proton for example. Steam famously packages its own libraries instead of using the system provided ones, so it makes sense that you see different results compared to other apps like the web browser. To make things more complicated, some apps access a lower-level API when dealing with DualSense in order to properly support gyro, acceleration, and force feedback (which is why gamepad tester behave differently than the other website which uses hid)

To try and narrow this down a little it would be very helpful if you could provide the followings:

• exact SDL version installed in your system
• if you could compile this little tool https://github.com/games-on-whales/sdl-jstest and report exactly what works and what doesn't that would be extremely helpful. I should probably improve the readme, feel free to ask if you get stuck.
  Once it's compiled you should be able to run it with:

sdl2-jstest --gamecontroller 0

You should get an output like the following:

I have solved some of the issues, and those were my fault.

gamepad tester: working
I made a lot of tests all afternoon and in the end I tried to install sunshine on my laptop (which also runs KDE but is rarely used so is a lot less bloated of packages).
And I saw that everything was working with sunshine on the laptop. So I started to remove every package with any reference to controllers/gamepad/udev/etc... that was not also present on my laptop.

Now gamepad tester recognize all the inputs.

KDE: still strange behavior
KDE still shows strange outputs but maybe they are correct (they are harder to interpret)
When connecting ds5 directly to PC the device is: /dev/hidraw
The number of buttons is 17 (there are 17 buttons on the ds5), the axes value represent the sticks axes and the triggers.
When connecting through sunshine as you can see below the device is /dev/input/event.
This is probably normal since the signals are passed in a different way, but the number of buttons is 13 and the axis behavior does not make any sense.

This behavior is reproduced also when sunshine is running on my laptop.

testing on games
I was able to test the controller on two non-steam games. Horizon forbidden west and final fantasy 7 remake. In both the ds5 works when directly connected to the PC and does not work when connected through sunshine.

sdl2-jstest
@ABeltramo thank you for the explanation (and thank you for the controller commits).
I did install the tool and everything is correctly recognized, either when directly connected to the PC/server or through sunshine.
As for the version that I am using of sdl:

local/lib32-sdl12-compat 1.2.68-2
local/lib32-sdl2 2.30.10-1
local/sdl12-compat 1.2.68-2
local/sdl2 2.30.10-1

Thanks for the detailed report!

If sdl2-jstest works correctly that means that your system SDL is correctly handling everything, we can exclude a whole lot of issues this way.
I wouldn't mind too much the KDE joypad tester, I'm more curious about those non-Steam games; how are you running them? When you say they don't work do you mean that nothing works or just some buttons/features?

The only other thing I could think of is that there are some things that we don't support like the microphone (Moonlight doesn't support it) and Haptic Feedback (I've never bothered implementing it since so few titles supports it). I think both those games should have full DualSense support, so I wonder if the game fails to pick up the pad because we miss something specific that they require from a (virtual) PS5 joypad..

Do you have any other non-Steam and non ex PS exclusive game to test? 😅

Also,

When connecting ds5 directly to PC the device is: /dev/hidraw
When connecting through sunshine as you can see below the device is /dev/input/event.

can you check permissions on the created/dev/hidraw when using Sunshine?
Our virtual devices should also make an entry down there just like the real PS pad, but, depending on the udev rules, that might be mounted as root (or as a different group) and, if your user is not able to open that device then you might experience these issues..

/dev/hidraw
if I connect the pad directly hidraw7 is created with owned by root group with permission
crw-rw----+ 1 root 240, 7 Dec 21 09:42 hidraw7
plus my own user is assigned rw permissions.
If I connect the pad through sunshine the hidraw created has exactly the same permissions.
Note: /dev/input/event28 has a different owner: the input group. No specific permission for my user.

Horizon Forbidden West: In general nothing happens like if no input is received at all by the game, but if I smash all the buttons randomly sometimes something happens, but it does not seems to be linked to specific buttons.
FF7 remake: when opening the main menu I received an alert, something like: unknown Dinput detected, and then the control page opens and I have to manually assign each gamepad input to the game action (attack, select, move etc...). Still it didn't seem to work.

I checked a lot of game on my library yesterday, unluckly my non-steam game catalogue has few games that are made with a gamepad in mind. Also those that have a gamepad in mind tends to be old and may not have support for ds5. Those were the two I found that had working support when directly connected. Witcher 2 recognized the input as an Xbox controller but I didn't test it throught sunshine.

I will be out for the holidays, but if you think it is worth it I can do some more tests on my return.

Note: /dev/input/event28 has a different owner: the input group. No specific permission for my user.

That is tied to Sunshine's installed udev rules, what permissions do you have for the joypad when plugged in the host? Are you part of the input group?

As for the two games, could you share a bit more info on how are you installing and running them? Is it via Heroic/Lutris? Which Proton version are you using?

I will be out for the holidays, but if you think it is worth it I can do some more tests on my return.

No worries, enjoy your holidays!!

I am also experiencing this issue on Fedora 41 on KDE. DualSense controllers work fine in and out of Steam while hardwired, however the virtual gamepad presented by Sunshine is only recognized and receives input properly through Steam. There are games that have native DualSense support launched from Steam that outright do not recognize any input from Sunshine when it is configured as a DualSense controller, but the input works fine when Sunshine is configured to always send an Xinput controller (so I lose the benefits of native DualSense support). I'd be happy to pick up where OP left off!

My user is part of the input group.
As far as udev rules, I have the default ones that come with Steam installed for certain but I believe Sunshine installs a set of rules as well, is that correct? Where should I go looking for udev rules? I can share them here for your evaluation.

There are games that have native DualSense support launched from Steam that outright do not recognize any input from Sunshine

Which games specifically? Are you running them with or without Steam Input enabled?

There are some DualSense only features that we haven't implemented yet like microphone, haptic feedback, and a few others; so I can't exclude that some game will fail some specific check. Is there any cheap game that I can buy to test this out? 😅

There are games that have native DualSense support launched from Steam that outright do not recognize any input from Sunshine

Which games specifically? Are you running them with or without Steam Input enabled?

There are some DualSense only features that we haven't implemented yet like microphone, haptic feedback, and a few others; so I can't exclude that some game will fail some specific check. Is there any cheap game that I can buy to test this out? 😅

It's any and all games that have native DualSense support when I have Steam Input disabled. If I recall correctly, if I enable Steam Input, the controller works, but of course with none of the native DualSense features available because the inputs are now being translated through Steam.

For a cheap game, Signalis would be a good example. It's $20 on Steam (and a great survival horror game to boot if you haven't played it and like that sort of game, so bonus there).

I don't know if this helps, but I noticed a weird button mapping in Forbidden West when I used inputtino (the joypad backend used by sunshine) in my application. I don't know the exact buttons that were wrongly mapped, but at least the options and share buttons were registering as R3 and L3 I believe. I assumed it was because of my use of inputtino, but seeing this issue makes me think something else could be the issue.

I intend to look more into this problem for my application in the coming week(s), hopefully I can share some information about any issue I might find 🤷 . To be continued :).

Thanks for all the reports, I can definitely reproduce this on my side too.
I'm joining the dots and I think I've got a grasp on what the actual underlying issue is (we've discussed the details in the Moonlight Discord server if anyone is interested). I'm going to work on it over the next few days, I'll keep you guys updated.

In the meantime, I'm afraid you have to use Steam Input for those titles..

Thanks for all the reports, I can definitely reproduce this on my side too. I'm joining the dots and I think I've got a grasp on what the actual underlying issue is (we've discussed the details in the Moonlight Discord server if anyone is interested). I'm going to work on it over the next few days, I'll keep you guys updated.

In the meantime, I'm afraid you have to use Steam Input for those titles..

Rockstar. Thank you for your time and effort! When you have a potential fix, I'm happy to help test! I'll also join the Moonlight discord so I can interact there as well.

PR is open: #3600 let me know if this fixes it for you too guys, seems to work really well on my end!

PR is open: #3600 let me know if this fixes it for you too guys, seems to work really well on my end!

After a series of monumental mistakes, I broke my Fedora partition and ended up on a fresh install of Arch instead, so I don't have the build deps setup right at the moment. I'll get the deps installed and try and build your PR to see if it works for me!

You can use the artifacts directly. It's not necessary to self compile. https://github.com/LizardByte/Sunshine/actions/runs/12995796078?pr=3600#artifacts

Alright, short version: I've done some testing on Arch and Fedora 41. I have mostly successes, but some failures.

• Helldivers 2: Works!
• Horizon Forbidden West: Works!
• Horizon Zero Dawn RM: Works!
• God of War Ragnarok: Doesn't work. :( (see notes)
• Signalis: Doesn't work. :( (see notes)

Notes:

• I also tested God of War Ragnarok at the console of the host machine with a wired DualSense controller and...that didn't work either when it had before. I'm assuming a recent patch broke the native DS support for the game itself and they need to fix it?
• I did the same thing with Signalis, and that DID work natively in front of the computer with the wired controller...but not consistently?

I'm going through some stuff in my personal life, so I can't commit to more testing in the short term (unfortunately).

However, based on my testing and that the two games that didn't work for me either also had trouble natively, I'd say this fix is ready to go with pretty high compatibility.

@JustPlainGarak thanks for testing!

I've just tried God of War Ragnarok on my end too and yeah, when plugging the real DualSense to the host it doesn't work either, so I don't think there's anything that we can do there. Found a few mentions that confirms that here: ValveSoftware/Proton#8107 (comment) (might be that SteamDeck=1 required setting to start the game?).

As for Signalis, I don't have that game. I can see on the Proton DB page that there's a complaint about not supporting the DualSense without Steam Input enabled, so maybe it's the game?

I'm going through some stuff in my personal life, so I can't commit to more testing in the short term

Take care, definitely no need to stress over this!