LizardByte
Sunshine virtual Dualsense controller registers with new ids every new session
Is there an existing issue for this?
- [X] I have searched the existing issues
Is your issue described in the documentation?
- [X] I have read the documentation
Is your issue present in the latest beta/pre-release?
This issue is present in the latest pre-release
Describe the Bug
When using steam with a dualsense gamepad I've noticed that the controller settings such as adjusting the deadzone or enabling rumble weren't "saving" after exiting and re-entering a sunshine session. Upon further investigation I noticed that the steam controller configuration utility was creating new profiles for each session, as if I was using a differen't controller each time, each marked with a unique id.
Here is a listing of some of the files in ~/.steam/steam/steamapps/common/Steam Controller Configs/<user id>/config/ that were created in a short time while debugging this issue:
nov 16 17:23 preferences_DSef07194a5c1d.vdf
nov 16 17:21 configset_controller_ps5.vdf
nov 16 17:21 configset_DSef07194a5c1d.vdf
nov 16 17:13 preferences_DS2c96dc8a35d4.vdf
nov 16 17:13 configset_DS2c96dc8a35d4.vdf
nov 16 17:12 preferences_DS2ab093035886.vdf
nov 16 17:10 configset_DS2ab093035886.vdf
nov 16 17:08 steam_autocloud.vdf
nov 16 17:03 preferences_DS1772a2de5625.vdf
nov 16 17:01 configset_DS1772a2de5625.vdf
nov 16 16:53 preferences_DSa5324fc07c7c.vdf
nov 16 16:51 configset_DSa5324fc07c7c.vdf
Each set of files is clearly marked with a unique id that ideally should not change across session since it is the same controller.
By looking at the kernel logs you can cross-reference the ids present in those config file names with ones registered by hidraw/uhid (?):
[nov16 16:51] input: Touch passthrough as /devices/virtual/input/input84
[ +0,000115] input: Pen passthrough as /devices/virtual/input/input85
[ +0,116280] playstation 0003:054C:0CE6.000B: hidraw6: USB HID v81.11 Gamepad [Sunshine DualSense (virtual) pad] on a5:32:4f:c0:7c:7c
[ +0,000044] input: Sunshine DualSense (virtual) pad as /devices/virtual/misc/uhid/0003:054C:0CE6.000B/input/input86
[ +0,000044] input: Sunshine DualSense (virtual) pad Motion Sensors as /devices/virtual/misc/uhid/0003:054C:0CE6.000B/input/input87
[ +0,000027] input: Sunshine DualSense (virtual) pad Touchpad as /devices/virtual/misc/uhid/0003:054C:0CE6.000B/input/input88
[ +0,000098] playstation 0003:054C:0CE6.000B: Registered DualSense controller hw_version=0x01000208 fw_version=0x01000036
[nov16 17:01] input: Touch passthrough as /devices/virtual/input/input89
[ +0,000120] input: Pen passthrough as /devices/virtual/input/input90
[ +0,120389] playstation 0003:054C:0CE6.000C: hidraw6: USB HID v81.11 Gamepad [Sunshine DualSense (virtual) pad] on 17:72:a2:de:56:25
[ +0,000043] input: Sunshine DualSense (virtual) pad as /devices/virtual/misc/uhid/0003:054C:0CE6.000C/input/input91
[ +0,000040] input: Sunshine DualSense (virtual) pad Motion Sensors as /devices/virtual/misc/uhid/0003:054C:0CE6.000C/input/input92
[ +0,000031] input: Sunshine DualSense (virtual) pad Touchpad as /devices/virtual/misc/uhid/0003:054C:0CE6.000C/input/input93
[ +0,000092] playstation 0003:054C:0CE6.000C: Registered DualSense controller hw_version=0x01000208 fw_version=0x01000036
[nov16 17:10] input: Touch passthrough as /devices/virtual/input/input94
[ +0,000104] input: Pen passthrough as /devices/virtual/input/input95
[ +0,107964] playstation 0003:054C:0CE6.000D: hidraw6: USB HID v81.11 Gamepad [Sunshine DualSense (virtual) pad] on 2a:b0:93:3:58:86
[ +0,000053] input: Sunshine DualSense (virtual) pad as /devices/virtual/misc/uhid/0003:054C:0CE6.000D/input/input96
[ +0,000047] input: Sunshine DualSense (virtual) pad Motion Sensors as /devices/virtual/misc/uhid/0003:054C:0CE6.000D/input/input97
[ +0,000034] input: Sunshine DualSense (virtual) pad Touchpad as /devices/virtual/misc/uhid/0003:054C:0CE6.000D/input/input98
[ +0,000107] playstation 0003:054C:0CE6.000D: Registered DualSense controller hw_version=0x01000208 fw_version=0x01000036
[nov16 17:13] input: Touch passthrough as /devices/virtual/input/input99
[ +0,000132] input: Pen passthrough as /devices/virtual/input/input100
[ +0,105293] playstation 0003:054C:0CE6.000E: hidraw6: USB HID v81.11 Gamepad [Sunshine DualSense (virtual) pad] on 2c:96:dc:8a:35:d4
[ +0,000051] input: Sunshine DualSense (virtual) pad as /devices/virtual/misc/uhid/0003:054C:0CE6.000E/input/input101
[ +0,000058] input: Sunshine DualSense (virtual) pad Motion Sensors as /devices/virtual/misc/uhid/0003:054C:0CE6.000E/input/input102
[ +0,000047] input: Sunshine DualSense (virtual) pad Touchpad as /devices/virtual/misc/uhid/0003:054C:0CE6.000E/input/input103
[ +0,000095] playstation 0003:054C:0CE6.000E: Registered DualSense controller hw_version=0x01000208 fw_version=0x01000036
[nov16 17:21] input: Touch passthrough as /devices/virtual/input/input104
[ +0,000138] input: Pen passthrough as /devices/virtual/input/input105
[ +0,124731] playstation 0003:054C:0CE6.000F: hidraw6: USB HID v81.11 Gamepad [Sunshine DualSense (virtual) pad] on ef:7:19:4a:5c:1d
[ +0,000042] input: Sunshine DualSense (virtual) pad as /devices/virtual/misc/uhid/0003:054C:0CE6.000F/input/input106
[ +0,000039] input: Sunshine DualSense (virtual) pad Motion Sensors as /devices/virtual/misc/uhid/0003:054C:0CE6.000F/input/input107
[ +0,000029] input: Sunshine DualSense (virtual) pad Touchpad as /devices/virtual/misc/uhid/0003:054C:0CE6.000F/input/input108
[ +0,000088] playstation 0003:054C:0CE6.000F: Registered DualSense controller hw_version=0x01000208 fw_version=0x01000036
I've looked around in the bugtracker expecting this issue to already be reported but couldn't find any. Could this be an issue unique to my setup? Can anyone else reproduce this behavior?
Expected Behavior
Virtual controller ids of the same real controller should remain the same across sessions.
Additional Context
No response
Host Operating System
Linux
Operating System Version
Fedora Workstation 41
Architecture
amd64/x86_64
Sunshine commit or version
2024.1115.40818
Package
Linux - Fedora Copr
GPU Type
AMD
GPU Model
Radeon RX 6700 XT
GPU Driver/Mesa Version
24.2.6
Capture Method
KMX (Linux)
Config
No response
Apps
No response
Relevant log output
relevant logs in the description of the bug
When using steam with a dualsense gamepad I've noticed that the controller settings such as adjusting the deadzone or enabling rumble weren't "saving" after exiting and re-entering a sunshine session. Upon further investigation I noticed that the steam controller configuration utility was creating new profiles for each session, as if I was using a different controller each time, each marked with a unique id.
I haven't investigated this, but I may be able to corroborate. I've noticed these symptoms since moving from a version 0.23.1 install to an install built from source. I assumed the issue was due to me missing something in the build, but perhaps it's not. I've worked around it by saving controller schemes in steam so I can just re-assign the full correct mapping. I can try to check for these changing ID's sometime this week.
TL:DR: To do it properly, we would need to extend the Moonlight protocol to get more info about the plugged controller from the client.
I assume this is tied to the fact that we generate a random MAC address every time we create a new joypad. There are a few options here, like generating the same address based on the "controller number" or maybe based on the client ID?
All these options will not really work if you swap joypads around. Ex: you adjust the deadzone in Steam for pad "1" and then on the next session you plug a different controller; in this case you don't want it to be persistent.
I'll take a look back at the code and see what we can realistically do. Ideally, it should be Moonlight to give us a unique identifier for the pad..
Are there any news on this issue? I've been having this problem when using a dualsense with the steam deck. When reordering the gamepads on steam (on the host pc) it shows as if I have multiple controllers registered. The workaround I have for now is using VirtualHere, but for some games this causes double inputs or conflicts with the virtual controller that's created for the steam deck
When reordering the gamepads on steam (on the host pc) it shows as if I have multiple controllers registered.
That sounds like a different issue compared to what was discussed here. Nobody above reported multiple controllers registered, perhaps since you are using a Steam Deck you just see the integrated xbox-like controller and the additional bluetooth/usb DualSense joypad?
I would need more info on your setup and exactly what the issue is. It might be worth to open a separate issue
Sorry, maybe I didn't explain correctly. What I mean is that when reordering steam shows a number besides the controller on the list. If I try to put the virtual controller created for the steam deck on the bottom of that list, that number increases every time I start the stream with the dualsense connected. It's as if steam is recognising that a new controller was connected every time. When I tried to fix that I noticed that steam thought I had connected dozens of different controllers when I only ever connected the dualsense and the virtual one from sunshine. It's related to this issue, since sunshine is registering the dualsense with a new id every time, steam assumes that the controller is a new one and creates a new entry on its list of controllers. So yes, I only have the dualsense and the virtual steam deck controller connected, but steam thinks I connected a new controller even though it's the same.
Right, I see it now. The missing bit was on each re-connection.
Yeah, the system will see a "new" joypad each time you stop and resume the stream.
Yes, sorry for the confusion. This is more an issue on games that don't have hot swapping of controllers, and in those cases reordering them helps avoiding double inputs or the controller input not being recognised. And since currently steam thinks a new controller was connected, the reordering is reset and breaks every time. But I just wanted to know if there are any updates on the issue.
But I just wanted to know if there are any updates on the issue.
Not really, I'm afraid this is a bit tricky to get right given that we don't have the necessary information from Moonlight to begin with.
The thing is that from the protocol, in Sunshine, we just get something like: "user has plugged a PS joypad". That's it, we don't have any more information about it, and we only have the "plugged" event which is used both for proper USB/BT hot plug and just to signal that on a new streaming session there's indeed a joypad plugged.
So, by default, we decide to just create a new virtual joypad when one has been "plugged". The current behaviour, for example, works correctly when you resume a session with a different joypad plugged.
What we could do is to change the default to be "if PS joypad was previously connected on the slot 1, then a new connection means that it's the same joypad" which will break the previous example but fixes this issue.
I suppose we could add a config in the setting page for this behaviour, but it doesn't really feel as a solution..
On the other hand, Moonlight clients will know exactly what kind of joypad is plugged locally and they should send more info about it; like a MAC address (or any kind of sensible UUID for a joypad) so that we could always take the correct approach in Sunshine.
I'm curious if this is related to a "bug" I've encountered with the Virtual DualSense controller that Sunshine plugs in when I connect to my session.
It's limited in scope to Steam when Steam Input is enabled for a game and I'm using a non-default controller profile.
- The Steam Input controller mapping profile for the virtual controller is ALWAYS reverted to the default profile for the game and I have to go in and re-apply my saved custom profile. Usually I have to start the game before applying the correct profile.
- This does not affect physical controllers (Bluetooth and USB) - they retain the previously set non-default controller profiles.
- This has been the behavior on both a Fedora 41 and an Arch Sunshine host.
I'm happy to create a new bug report, but after reading over the behavior described in this issue I'm inclined to believe that the controller behavior I've experienced is due to the behavior described above.
I also noticed the behavior with steam and DS5 controller, but when I tested it with Switch Pro controller, steam can consistently recognize the controller being the same one. Does it mean moonlight can send the ID of the Switch Pro controller but not DS controller? If it can work with Switch Pro then it should be able to get fixed for DS?
I just tested it with a second Switch Pro controller and noticed that it is just sunshine will always generate the same id for any Switch Pro controller. so moonlight still need to send the real ID for this to get really fixed. it is a bit weird that sunshine has a different ID generation behavior for DS.
Does it mean moonlight can send the ID of the Switch Pro controller but not DS controller? If it can work with Switch Pro then it should be able to get fixed for DS?
Nope, it's just that under the hood Switch and Xbox virtual joypads are created and controlled via uinput whilst the DualSense pad is created via uhid. This is so that we can properly support advanced features like motion, gyro, touchpad and adaptive triggers.
Any chance we can add an option for HID to not auto randomize the MAC address? That would solve the issue for use re-connecting. That seems to be a bit more of a common operation than controller swapping.
What we could do is to change the default to be "if PS joypad was previously connected on the slot 1, then a new connection means that it's the same joypad" which will break the previous example but fixes this issue.
I suppose we could add a config in the setting page for this behaviour, but it doesn't really feel as a solution..
On the other hand, Moonlight clients will know exactly what kind of joypad is plugged locally and they should send more info about it; like a MAC address (or any kind of sensible UUID for a joypad) so that we could always take the correct approach in Sunshine.
Could this config setting be implemented as a non-default option for clients that do not support providing extended controller information on sunshine linux? Once there is a Moonlight version supporting the correct behavior the option setting should be ignored for those. The Windows implementation for DS4 seems to do just what you're describing above (similar to XBox/Switch Controller).
It is really annoying to have to manually enable rumble in SteamInput each time a Steam stream is (re-)started/ or DS Controller is (re-)connected. So far the only workaround for me is forcing sunshine to emulate an XBox Controller with all the drawbacks that entails.
I've just had a look at the controller configs that steam generates and the files include the MAC for the controller (hence settings seemingly getting lost when reconnecting). So for the above mentioned "workaround" config option it should be sufficient to just generate a MAC based on the controller slot (00:00:00:00:00:0{slotnumber-in-hex} should suffice for up to 16) and have inputtino accept it instead of generating a random mac upon controller creation (might have to be implemented there if not yet available). This should make the behaviour be similar to how XBox- and Switch-Controllers (and DS4 on Windows) are handled.
So for the above mentioned "workaround" config option it should be sufficient to just generate a MAC based on the controller slot (00:00:00:00:00:0{slotnumber-in-hex} should suffice for up to 16) and have inputtino accept it instead of generating a random mac upon controller creation (might have to be implemented there if not yet available).
Inputtino already supports that, when creating a device in here that DeviceDefinition struct has two more strings: device_phys and device_uniq. Since they aren't passed inputtino defaults to creating two random address here. Eventually they'll get passed straight to uhid via the UHID_CREATE2 request filling these two params.
Adding the workaround proposed above shouldn't be complex, unfortunately I don't have the bandwidth to work on it at the moment. If anyone wants to start a PR I'd be happy to review, test and help though (make sure to ping me!)
I haven't coded in C++ for like 20 years but i've tried to create a suitable PR that should implement this option (hopefully correctly). Haven't had time to test this (therefore just a draft) and probably won't be able to do so until next week so if anyone else wants to give it a shot feel free to do so.
I can't re-open the issue but today's pre-release (2025.816.231536) does not fix this just yet as it's just the Sunshine side merged and the Inputtino fix will be pulled in a separate PR by dependabot (as it seemed more logical to me to follow the usual workflow for third-party dependencies in Sunshine).
Until then then option is visually there but the inputtino-side does not handle the fixed MAC that is passed by Sunshine correctly. I'll post an update with the dependabot PR here once it is up and/or merged.
@Kishi85 wanted to wait until a build later than 818 landed in my distro's repo (CachyOS), upgraded now to 2025.924.154138, but I'm still seeing multiple MAC addresses being created (on each client connect). Is there an option in the sunshine.conf I need to add as well?
ah sorry, found it, for anybody else looking:
in your sunshine.conf, add:
ds5_inputtino_randomize_mac=disabled