feat(input/linux): allow ds5 gamepads to have a fixed device mac based on controller index

[Kishi85]

Description

This PR adds an option to change how virtual DS5 controllers are created that allows them to retain controller settings (when stored based on the virtual devices MAC-Address, like Steam does) by disabling the random MAC generation and manually specifiying a private MAC-based on the connected gamepads global index. The behaviour then should be equal to the way XBox- and Switchcontrollers and DS4 on Windows are handled currently.

Screenshot

Issues Fixed or Closed

• ResolvesSunshine virtual Dualsense controller registers with new ids every new session #3404

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[ReenigneArcher]

Thank you for the PR! I just have two comments below.

[codecov]

Bundle Report

Changes will increase total bundle size by 1.29kB (0.07%) ⬆️. This is within the configured threshold ✅

Detailed changes

Bundle name	Size	Change
sunshine-esm	1.75MB	1.29kB (0.07%) ⬆️

Affected Assets, Files, and Routes:

view changes for bundle: sunshine-esm

Assets Changed:

Asset Name	Size Change	Total Size	Change (%)
assets/_plugin-*.js	343 bytes	342.53kB	0.1%
assets/config-*.js	952 bytes	58.75kB	1.65%

[codecov]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 12.46%. Comparing base (7895440) to head (ee38c35).
⚠️ Report is 2 commits behind head on master.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/config.cpp	0.00%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #4158 +/- ##
==========================================
+ Coverage 11.60% 12.46% +0.86% 
==========================================
Files 69 66 -3 Lines 12367 12458 +91 Branches 5862 5758 -104 ==========================================
+ Hits 1435 1553 +118 + Misses 10507 10448 -59 - Partials 425 457 +32 

Flag	Coverage Δ
Linux-AppImage	?
Windows-AMD64	12.46% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/config.h	0.00% <ø> (ø)
src/config.cpp	0.00% <0.00%> (ø)

... and 78 files with indirect coverage changes

[Kishi85]

I've taken the time to test this a bit today and after removing the hex base prefix it is working as intended but the current static mac prefix is not working with Steam the way it should (probably because it is classed as a private mac). I'll do some further testing and probably have to update the used prefix before this can be merged for the desired effect.

EDIT: Further testing shows that with randomized MAC by inputtino the Steam preferences filename matches the generated MAC but with the statically created one it does not work and steam randomizes the config. Could this be a weird string formatting problem?

[ABeltramo]

Thanks for working on this, the PR looks good!
I've tested this locally and I think I see where the issue is: inputtino always generates a random MAC address and that will most likely mess up the matching.

You can easily check the output HID_PHYS and HID_UNIQ using

udevadm monitor -u -p

and hot-plugging the device during a stream.

As a side note, my original comment was kind of wrong.. PHYS is just the "physical path" of the device in the system, such as the USB port or Bluetooth connection. It's most likely not being used for matching, so we can definitely leave that one out. Not sure if HID_PHYS is generated based on a combination of things (including the MAC address?), I'll have to test it better.

I'm going to add something in inputtino that controls the MAC address generation, that's most likely the only thing needed to fix this..

[Kishi85]

Thanks for working on this, the PR looks good! I've tested this locally and I think I see where the issue is: inputtino always generates a random MAC address and that will most likely mess up the matching.

You can easily check the output HID_PHYS and HID_UNIQ using

udevadm monitor -u -p

and hot-plugging the device during a stream.

As a side note, my original comment was kind of wrong.. PHYS is just the "physical path" of the device in the system, such as the USB port or Bluetooth connection. It's most likely not being used for matching, so we can definitely leave that one out. Not sure if HID_PHYS is generated based on a combination of things (including the MAC address?), I'll have to test it better.

I'm going to add something in inputtino that controls the MAC address generation, that's most likely the only thing needed to fix this..

That sounds good as it would simplify things for use-cases like this. You could probably just use the value in device_uniq for the MAC-Address as long as it is valid.

I've seen that the generated mac is also used here and for that call it can't be specified manually. Maybe thats the main culprit?

EDIT: It's used throught the PS5Joypad-Implementation so being able to specify a value upon creation seems to be the only logical way

[Kishi85]

Can confirm that this requires the already mentioned changes to MAC handling in inputtino to work as intended. @ABeltramo I'll keep a look out on the fix on your side and adapt this PR if necessary.

To test this i did a rather quick hack on inputtino that parses back the mac from device_uniq to joypad._state before calling UHID create2 and then it is finally working in Steam. Here's the patch if anybody wants to try it:

diff -ruN a/third-party/inputtino/src/uhid/joypad_ps5.cpp sunshine/third-party/inputtino/src/uhid/joypad_ps5.cpp--- a/third-party/inputtino/src/uhid/joypad_ps5.cpp 2025-08-15 13:00:08.148557490 +0200+++ sunshine/third-party/inputtino/src/uhid/joypad_ps5.cpp 2025-08-15 13:27:51.574081232 +0200@@ -8,6 +8,8 @@
#include <inputtino/input.hpp>
#include <iomanip>
#include <random>
+#include <regex>+#include <sstream>
#include <uhid/protected_types.hpp>
#include <uhid/ps5.hpp>
#include <uhid/uhid.hpp>
@@ -272,6 +274,16 @@
}
if (def.uniq.empty()) {
def.uniq = joypad.get_mac_address();
+ } else {+ if (std::regex_match(def.uniq, (std::regex) "^([0-9A-Fa-f]{2}[:]){5}([0-9A-Fa-f]{2})$")) {+ std::string item;+ std::stringstream mac = std::stringstream(def.uniq);+ int i = 0;+ while (std::getline(mac, item, ':')) {+ joypad._state->mac_address[i] = std::stoi(item, NULL, 16);+ i = i + 1;+ }+ }
}
auto dev =

[ABeltramo]

@Kishi85 I've just pushed a potential fix for this games-on-whales/inputtino#31

You should be able to just pass the device_uniq property in the canonical MAC address format like AA:00:CC:11:EE:22 and it should fix the matching issue for this issue. The phys shouldn't be needed, I've hardcoded INPUTTINO_BT_LINK if it's empty, but you can pass any String in theory. I don't think any SW relies on that..

I gave that a quick go, and it seems to be working for me, let me know if this fixes it for you too, and I'll merge the PR in inputtino.

[Kishi85]

@Kishi85 I've just pushed a potential fix for this games-on-whales/inputtino#31

You should be able to just pass the device_uniq property in the canonical MAC address format like AA:00:CC:11:EE:22 and it should fix the matching issue for this issue. The phys shouldn't be needed, I've hardcoded INPUTTINO_BT_LINK if it's empty, but you can pass any String in theory. I don't think any SW relies on that..

I gave that a quick go, and it seems to be working for me, let me know if this fixes it for you too, and I'll merge the PR in inputtino.

I've tested it and apart from that remark I left on the PR everything looks good to me and is working. I'm not sure whether I'll remove the device_phys from this PR tho I'll leave device_phys in for now as that is what is shown in dmesg after when the controller connects (otherwise it would show INPUTTINO_BT_LINK instead of the MAC address):

Example: hidraw5: BLUETOOTH HID v81.11 Gamepad [Sunshine PS5 (virtual) pad] on02:00:00:00:00:00

[ABeltramo]

I've tested it and apart from that remark I left on the PR everything looks good to me

You lost me there, which remark are you talking about?

[Kishi85]

I've tested it and apart from that remark I left on the PR everything looks good to me

You lost me there, which remark are you talking about?

My review about making the MAC parser safer by regex matching it beforehand on your PR at games-on-whales/inputtino#31

EDIT: Whoops. Forgot to submit, should be there now.

[Kishi85]

This is ready for merge on my end and @ABeltramo has updated inputtino so that device_uniq does what is necessary for this to fully work now.

Since I haven't worked that much with dependabot so far: Do I have to update the submodule in this PR or will dependabot put up a separate PR for inputtino?

[ReenigneArcher]

We could initialize the device_mac as empty and then set it only if needed, reducing the if/else block.

There's a few lint errors here: https://github.com/LizardByte/Sunshine/actions/runs/16984755077/job/48225412676?pr=4158#step:11:19

Otherwise, looks fine to me.

[Kishi85]

Done as requested. For this to fully work it requires the third-party/inputtino to be bumped to latest stable but i'm assuming dependabot will take care of this.

[ReenigneArcher]

For this to fully work it requires the third-party/inputtino to be bumped to latest stable but i'm assuming dependabot will take care of this.

Yes, dependabot will pick up any changes. Currently it runs daily (M-F), so should pick up on Monday.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Kishi85]

Description

This PR adds an option to change how virtual DS5 controllers are created that allows them to retain controller settings (when stored based on the virtual devices MAC-Address, like Steam does) by disabling the random MAC generation and manually specifiying a private MAC-based on the connected gamepads global index. The behaviour then should be equal to the way XBox- and Switchcontrollers and DS4 on Windows are handled currently.

Screenshot

Issues Fixed or Closed

• ResolvesSunshine virtual Dualsense controller registers with new ids every new session #3404

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[ReenigneArcher]

Thank you for the PR! I just have two comments below.

[codecov]

Bundle Report

Changes will increase total bundle size by 1.29kB (0.07%) ⬆️. This is within the configured threshold ✅

Detailed changes

Bundle name	Size	Change
sunshine-esm	1.75MB	1.29kB (0.07%) ⬆️

Affected Assets, Files, and Routes:

view changes for bundle: sunshine-esm

Assets Changed:

Asset Name	Size Change	Total Size	Change (%)
assets/_plugin-*.js	343 bytes	342.53kB	0.1%
assets/config-*.js	952 bytes	58.75kB	1.65%

[codecov]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 12.46%. Comparing base (7895440) to head (ee38c35).
⚠️ Report is 2 commits behind head on master.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/config.cpp	0.00%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #4158 +/- ##
==========================================
+ Coverage 11.60% 12.46% +0.86% 
==========================================
Files 69 66 -3 Lines 12367 12458 +91 Branches 5862 5758 -104 ==========================================
+ Hits 1435 1553 +118 + Misses 10507 10448 -59 - Partials 425 457 +32 

Flag	Coverage Δ
Linux-AppImage	?
Windows-AMD64	12.46% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/config.h	0.00% <ø> (ø)
src/config.cpp	0.00% <0.00%> (ø)

... and 78 files with indirect coverage changes

[Kishi85]

I've taken the time to test this a bit today and after removing the hex base prefix it is working as intended but the current static mac prefix is not working with Steam the way it should (probably because it is classed as a private mac). I'll do some further testing and probably have to update the used prefix before this can be merged for the desired effect.

EDIT: Further testing shows that with randomized MAC by inputtino the Steam preferences filename matches the generated MAC but with the statically created one it does not work and steam randomizes the config. Could this be a weird string formatting problem?

[ABeltramo]

Thanks for working on this, the PR looks good!
I've tested this locally and I think I see where the issue is: inputtino always generates a random MAC address and that will most likely mess up the matching.

You can easily check the output HID_PHYS and HID_UNIQ using

udevadm monitor -u -p

and hot-plugging the device during a stream.

As a side note, my original comment was kind of wrong.. PHYS is just the "physical path" of the device in the system, such as the USB port or Bluetooth connection. It's most likely not being used for matching, so we can definitely leave that one out. Not sure if HID_PHYS is generated based on a combination of things (including the MAC address?), I'll have to test it better.

I'm going to add something in inputtino that controls the MAC address generation, that's most likely the only thing needed to fix this..

[Kishi85]

Thanks for working on this, the PR looks good! I've tested this locally and I think I see where the issue is: inputtino always generates a random MAC address and that will most likely mess up the matching.

You can easily check the output HID_PHYS and HID_UNIQ using

udevadm monitor -u -p

and hot-plugging the device during a stream.

As a side note, my original comment was kind of wrong.. PHYS is just the "physical path" of the device in the system, such as the USB port or Bluetooth connection. It's most likely not being used for matching, so we can definitely leave that one out. Not sure if HID_PHYS is generated based on a combination of things (including the MAC address?), I'll have to test it better.

I'm going to add something in inputtino that controls the MAC address generation, that's most likely the only thing needed to fix this..

That sounds good as it would simplify things for use-cases like this. You could probably just use the value in device_uniq for the MAC-Address as long as it is valid.

I've seen that the generated mac is also used here and for that call it can't be specified manually. Maybe thats the main culprit?

EDIT: It's used throught the PS5Joypad-Implementation so being able to specify a value upon creation seems to be the only logical way

[Kishi85]

Can confirm that this requires the already mentioned changes to MAC handling in inputtino to work as intended. @ABeltramo I'll keep a look out on the fix on your side and adapt this PR if necessary.

To test this i did a rather quick hack on inputtino that parses back the mac from device_uniq to joypad._state before calling UHID create2 and then it is finally working in Steam. Here's the patch if anybody wants to try it:

diff -ruN a/third-party/inputtino/src/uhid/joypad_ps5.cpp sunshine/third-party/inputtino/src/uhid/joypad_ps5.cpp--- a/third-party/inputtino/src/uhid/joypad_ps5.cpp 2025-08-15 13:00:08.148557490 +0200+++ sunshine/third-party/inputtino/src/uhid/joypad_ps5.cpp 2025-08-15 13:27:51.574081232 +0200@@ -8,6 +8,8 @@
#include <inputtino/input.hpp>
#include <iomanip>
#include <random>
+#include <regex>+#include <sstream>
#include <uhid/protected_types.hpp>
#include <uhid/ps5.hpp>
#include <uhid/uhid.hpp>
@@ -272,6 +274,16 @@
}
if (def.uniq.empty()) {
def.uniq = joypad.get_mac_address();
+ } else {+ if (std::regex_match(def.uniq, (std::regex) "^([0-9A-Fa-f]{2}[:]){5}([0-9A-Fa-f]{2})$")) {+ std::string item;+ std::stringstream mac = std::stringstream(def.uniq);+ int i = 0;+ while (std::getline(mac, item, ':')) {+ joypad._state->mac_address[i] = std::stoi(item, NULL, 16);+ i = i + 1;+ }+ }
}
auto dev =

[ABeltramo]

@Kishi85 I've just pushed a potential fix for this games-on-whales/inputtino#31

You should be able to just pass the device_uniq property in the canonical MAC address format like AA:00:CC:11:EE:22 and it should fix the matching issue for this issue. The phys shouldn't be needed, I've hardcoded INPUTTINO_BT_LINK if it's empty, but you can pass any String in theory. I don't think any SW relies on that..

I gave that a quick go, and it seems to be working for me, let me know if this fixes it for you too, and I'll merge the PR in inputtino.

[Kishi85]

@Kishi85 I've just pushed a potential fix for this games-on-whales/inputtino#31

You should be able to just pass the device_uniq property in the canonical MAC address format like AA:00:CC:11:EE:22 and it should fix the matching issue for this issue. The phys shouldn't be needed, I've hardcoded INPUTTINO_BT_LINK if it's empty, but you can pass any String in theory. I don't think any SW relies on that..

I gave that a quick go, and it seems to be working for me, let me know if this fixes it for you too, and I'll merge the PR in inputtino.

I've tested it and apart from that remark I left on the PR everything looks good to me and is working. I'm not sure whether I'll remove the device_phys from this PR tho I'll leave device_phys in for now as that is what is shown in dmesg after when the controller connects (otherwise it would show INPUTTINO_BT_LINK instead of the MAC address):

Example: hidraw5: BLUETOOTH HID v81.11 Gamepad [Sunshine PS5 (virtual) pad] on02:00:00:00:00:00

[ABeltramo]

I've tested it and apart from that remark I left on the PR everything looks good to me

You lost me there, which remark are you talking about?

[Kishi85]

I've tested it and apart from that remark I left on the PR everything looks good to me

You lost me there, which remark are you talking about?

My review about making the MAC parser safer by regex matching it beforehand on your PR at games-on-whales/inputtino#31

EDIT: Whoops. Forgot to submit, should be there now.

[Kishi85]

This is ready for merge on my end and @ABeltramo has updated inputtino so that device_uniq does what is necessary for this to fully work now.

Since I haven't worked that much with dependabot so far: Do I have to update the submodule in this PR or will dependabot put up a separate PR for inputtino?

[ReenigneArcher]

We could initialize the device_mac as empty and then set it only if needed, reducing the if/else block.

There's a few lint errors here: https://github.com/LizardByte/Sunshine/actions/runs/16984755077/job/48225412676?pr=4158#step:11:19

Otherwise, looks fine to me.

[Kishi85]

Done as requested. For this to fully work it requires the third-party/inputtino to be bumped to latest stable but i'm assuming dependabot will take care of this.

[ReenigneArcher]

For this to fully work it requires the third-party/inputtino to be bumped to latest stable but i'm assuming dependabot will take care of this.

Yes, dependabot will pick up any changes. Currently it runs daily (M-F), so should pick up on Monday.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Kishi85]

Description

This PR adds an option to change how virtual DS5 controllers are created that allows them to retain controller settings (when stored based on the virtual devices MAC-Address, like Steam does) by disabling the random MAC generation and manually specifiying a private MAC-based on the connected gamepads global index. The behaviour then should be equal to the way XBox- and Switchcontrollers and DS4 on Windows are handled currently.

Screenshot

Issues Fixed or Closed

• ResolvesSunshine virtual Dualsense controller registers with new ids every new session #3404

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[ReenigneArcher]

Thank you for the PR! I just have two comments below.

[codecov]

Bundle Report

Changes will increase total bundle size by 1.29kB (0.07%) ⬆️. This is within the configured threshold ✅

Detailed changes

Bundle name	Size	Change
sunshine-esm	1.75MB	1.29kB (0.07%) ⬆️

Affected Assets, Files, and Routes:

view changes for bundle: sunshine-esm

Assets Changed:

Asset Name	Size Change	Total Size	Change (%)
assets/_plugin-*.js	343 bytes	342.53kB	0.1%
assets/config-*.js	952 bytes	58.75kB	1.65%

[codecov]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 12.46%. Comparing base (7895440) to head (ee38c35).
⚠️ Report is 2 commits behind head on master.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/config.cpp	0.00%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #4158 +/- ##
==========================================
+ Coverage 11.60% 12.46% +0.86% 
==========================================
Files 69 66 -3 Lines 12367 12458 +91 Branches 5862 5758 -104 ==========================================
+ Hits 1435 1553 +118 + Misses 10507 10448 -59 - Partials 425 457 +32 

Flag	Coverage Δ
Linux-AppImage	?
Windows-AMD64	12.46% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/config.h	0.00% <ø> (ø)
src/config.cpp	0.00% <0.00%> (ø)

... and 78 files with indirect coverage changes

[Kishi85]

I've taken the time to test this a bit today and after removing the hex base prefix it is working as intended but the current static mac prefix is not working with Steam the way it should (probably because it is classed as a private mac). I'll do some further testing and probably have to update the used prefix before this can be merged for the desired effect.

EDIT: Further testing shows that with randomized MAC by inputtino the Steam preferences filename matches the generated MAC but with the statically created one it does not work and steam randomizes the config. Could this be a weird string formatting problem?

[ABeltramo]

Thanks for working on this, the PR looks good!
I've tested this locally and I think I see where the issue is: inputtino always generates a random MAC address and that will most likely mess up the matching.

You can easily check the output HID_PHYS and HID_UNIQ using

udevadm monitor -u -p

and hot-plugging the device during a stream.

As a side note, my original comment was kind of wrong.. PHYS is just the "physical path" of the device in the system, such as the USB port or Bluetooth connection. It's most likely not being used for matching, so we can definitely leave that one out. Not sure if HID_PHYS is generated based on a combination of things (including the MAC address?), I'll have to test it better.

I'm going to add something in inputtino that controls the MAC address generation, that's most likely the only thing needed to fix this..

[Kishi85]

Thanks for working on this, the PR looks good! I've tested this locally and I think I see where the issue is: inputtino always generates a random MAC address and that will most likely mess up the matching.

You can easily check the output HID_PHYS and HID_UNIQ using

udevadm monitor -u -p

and hot-plugging the device during a stream.

As a side note, my original comment was kind of wrong.. PHYS is just the "physical path" of the device in the system, such as the USB port or Bluetooth connection. It's most likely not being used for matching, so we can definitely leave that one out. Not sure if HID_PHYS is generated based on a combination of things (including the MAC address?), I'll have to test it better.

I'm going to add something in inputtino that controls the MAC address generation, that's most likely the only thing needed to fix this..

That sounds good as it would simplify things for use-cases like this. You could probably just use the value in device_uniq for the MAC-Address as long as it is valid.

I've seen that the generated mac is also used here and for that call it can't be specified manually. Maybe thats the main culprit?

EDIT: It's used throught the PS5Joypad-Implementation so being able to specify a value upon creation seems to be the only logical way

[Kishi85]

Can confirm that this requires the already mentioned changes to MAC handling in inputtino to work as intended. @ABeltramo I'll keep a look out on the fix on your side and adapt this PR if necessary.

To test this i did a rather quick hack on inputtino that parses back the mac from device_uniq to joypad._state before calling UHID create2 and then it is finally working in Steam. Here's the patch if anybody wants to try it:

diff -ruN a/third-party/inputtino/src/uhid/joypad_ps5.cpp sunshine/third-party/inputtino/src/uhid/joypad_ps5.cpp--- a/third-party/inputtino/src/uhid/joypad_ps5.cpp 2025-08-15 13:00:08.148557490 +0200+++ sunshine/third-party/inputtino/src/uhid/joypad_ps5.cpp 2025-08-15 13:27:51.574081232 +0200@@ -8,6 +8,8 @@
#include <inputtino/input.hpp>
#include <iomanip>
#include <random>
+#include <regex>+#include <sstream>
#include <uhid/protected_types.hpp>
#include <uhid/ps5.hpp>
#include <uhid/uhid.hpp>
@@ -272,6 +274,16 @@
}
if (def.uniq.empty()) {
def.uniq = joypad.get_mac_address();
+ } else {+ if (std::regex_match(def.uniq, (std::regex) "^([0-9A-Fa-f]{2}[:]){5}([0-9A-Fa-f]{2})$")) {+ std::string item;+ std::stringstream mac = std::stringstream(def.uniq);+ int i = 0;+ while (std::getline(mac, item, ':')) {+ joypad._state->mac_address[i] = std::stoi(item, NULL, 16);+ i = i + 1;+ }+ }
}
auto dev =

[ABeltramo]

@Kishi85 I've just pushed a potential fix for this games-on-whales/inputtino#31

You should be able to just pass the device_uniq property in the canonical MAC address format like AA:00:CC:11:EE:22 and it should fix the matching issue for this issue. The phys shouldn't be needed, I've hardcoded INPUTTINO_BT_LINK if it's empty, but you can pass any String in theory. I don't think any SW relies on that..

I gave that a quick go, and it seems to be working for me, let me know if this fixes it for you too, and I'll merge the PR in inputtino.

[Kishi85]

@Kishi85 I've just pushed a potential fix for this games-on-whales/inputtino#31

You should be able to just pass the device_uniq property in the canonical MAC address format like AA:00:CC:11:EE:22 and it should fix the matching issue for this issue. The phys shouldn't be needed, I've hardcoded INPUTTINO_BT_LINK if it's empty, but you can pass any String in theory. I don't think any SW relies on that..

I gave that a quick go, and it seems to be working for me, let me know if this fixes it for you too, and I'll merge the PR in inputtino.

I've tested it and apart from that remark I left on the PR everything looks good to me and is working. I'm not sure whether I'll remove the device_phys from this PR tho I'll leave device_phys in for now as that is what is shown in dmesg after when the controller connects (otherwise it would show INPUTTINO_BT_LINK instead of the MAC address):

Example: hidraw5: BLUETOOTH HID v81.11 Gamepad [Sunshine PS5 (virtual) pad] on02:00:00:00:00:00

[ABeltramo]

I've tested it and apart from that remark I left on the PR everything looks good to me

You lost me there, which remark are you talking about?

[Kishi85]

I've tested it and apart from that remark I left on the PR everything looks good to me

You lost me there, which remark are you talking about?

My review about making the MAC parser safer by regex matching it beforehand on your PR at games-on-whales/inputtino#31

EDIT: Whoops. Forgot to submit, should be there now.

[Kishi85]

This is ready for merge on my end and @ABeltramo has updated inputtino so that device_uniq does what is necessary for this to fully work now.

Since I haven't worked that much with dependabot so far: Do I have to update the submodule in this PR or will dependabot put up a separate PR for inputtino?

[ReenigneArcher]

We could initialize the device_mac as empty and then set it only if needed, reducing the if/else block.

There's a few lint errors here: https://github.com/LizardByte/Sunshine/actions/runs/16984755077/job/48225412676?pr=4158#step:11:19

Otherwise, looks fine to me.

[Kishi85]

Done as requested. For this to fully work it requires the third-party/inputtino to be bumped to latest stable but i'm assuming dependabot will take care of this.

[ReenigneArcher]

For this to fully work it requires the third-party/inputtino to be bumped to latest stable but i'm assuming dependabot will take care of this.

Yes, dependabot will pick up any changes. Currently it runs daily (M-F), so should pick up on Monday.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Kishi85]

Description

This PR adds an option to change how virtual DS5 controllers are created that allows them to retain controller settings (when stored based on the virtual devices MAC-Address, like Steam does) by disabling the random MAC generation and manually specifiying a private MAC-based on the connected gamepads global index. The behaviour then should be equal to the way XBox- and Switchcontrollers and DS4 on Windows are handled currently.

Screenshot

Issues Fixed or Closed

• ResolvesSunshine virtual Dualsense controller registers with new ids every new session #3404

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[ReenigneArcher]

Thank you for the PR! I just have two comments below.

[codecov]

Bundle Report

Changes will increase total bundle size by 1.29kB (0.07%) ⬆️. This is within the configured threshold ✅

Detailed changes

Bundle name	Size	Change
sunshine-esm	1.75MB	1.29kB (0.07%) ⬆️

Affected Assets, Files, and Routes:

view changes for bundle: sunshine-esm

Assets Changed:

Asset Name	Size Change	Total Size	Change (%)
assets/_plugin-*.js	343 bytes	342.53kB	0.1%
assets/config-*.js	952 bytes	58.75kB	1.65%

[codecov]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 12.46%. Comparing base (7895440) to head (ee38c35).
⚠️ Report is 2 commits behind head on master.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/config.cpp	0.00%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #4158 +/- ##
==========================================
+ Coverage 11.60% 12.46% +0.86% 
==========================================
Files 69 66 -3 Lines 12367 12458 +91 Branches 5862 5758 -104 ==========================================
+ Hits 1435 1553 +118 + Misses 10507 10448 -59 - Partials 425 457 +32 

Flag	Coverage Δ
Linux-AppImage	?
Windows-AMD64	12.46% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/config.h	0.00% <ø> (ø)
src/config.cpp	0.00% <0.00%> (ø)

... and 78 files with indirect coverage changes

[Kishi85]

I've taken the time to test this a bit today and after removing the hex base prefix it is working as intended but the current static mac prefix is not working with Steam the way it should (probably because it is classed as a private mac). I'll do some further testing and probably have to update the used prefix before this can be merged for the desired effect.

EDIT: Further testing shows that with randomized MAC by inputtino the Steam preferences filename matches the generated MAC but with the statically created one it does not work and steam randomizes the config. Could this be a weird string formatting problem?

[ABeltramo]

Thanks for working on this, the PR looks good!
I've tested this locally and I think I see where the issue is: inputtino always generates a random MAC address and that will most likely mess up the matching.

You can easily check the output HID_PHYS and HID_UNIQ using

udevadm monitor -u -p

and hot-plugging the device during a stream.

As a side note, my original comment was kind of wrong.. PHYS is just the "physical path" of the device in the system, such as the USB port or Bluetooth connection. It's most likely not being used for matching, so we can definitely leave that one out. Not sure if HID_PHYS is generated based on a combination of things (including the MAC address?), I'll have to test it better.

I'm going to add something in inputtino that controls the MAC address generation, that's most likely the only thing needed to fix this..

[Kishi85]

Thanks for working on this, the PR looks good! I've tested this locally and I think I see where the issue is: inputtino always generates a random MAC address and that will most likely mess up the matching.

You can easily check the output HID_PHYS and HID_UNIQ using

udevadm monitor -u -p

and hot-plugging the device during a stream.

As a side note, my original comment was kind of wrong.. PHYS is just the "physical path" of the device in the system, such as the USB port or Bluetooth connection. It's most likely not being used for matching, so we can definitely leave that one out. Not sure if HID_PHYS is generated based on a combination of things (including the MAC address?), I'll have to test it better.

I'm going to add something in inputtino that controls the MAC address generation, that's most likely the only thing needed to fix this..

That sounds good as it would simplify things for use-cases like this. You could probably just use the value in device_uniq for the MAC-Address as long as it is valid.

I've seen that the generated mac is also used here and for that call it can't be specified manually. Maybe thats the main culprit?

EDIT: It's used throught the PS5Joypad-Implementation so being able to specify a value upon creation seems to be the only logical way

[Kishi85]

Can confirm that this requires the already mentioned changes to MAC handling in inputtino to work as intended. @ABeltramo I'll keep a look out on the fix on your side and adapt this PR if necessary.

To test this i did a rather quick hack on inputtino that parses back the mac from device_uniq to joypad._state before calling UHID create2 and then it is finally working in Steam. Here's the patch if anybody wants to try it:

diff -ruN a/third-party/inputtino/src/uhid/joypad_ps5.cpp sunshine/third-party/inputtino/src/uhid/joypad_ps5.cpp--- a/third-party/inputtino/src/uhid/joypad_ps5.cpp 2025-08-15 13:00:08.148557490 +0200+++ sunshine/third-party/inputtino/src/uhid/joypad_ps5.cpp 2025-08-15 13:27:51.574081232 +0200@@ -8,6 +8,8 @@
#include <inputtino/input.hpp>
#include <iomanip>
#include <random>
+#include <regex>+#include <sstream>
#include <uhid/protected_types.hpp>
#include <uhid/ps5.hpp>
#include <uhid/uhid.hpp>
@@ -272,6 +274,16 @@
}
if (def.uniq.empty()) {
def.uniq = joypad.get_mac_address();
+ } else {+ if (std::regex_match(def.uniq, (std::regex) "^([0-9A-Fa-f]{2}[:]){5}([0-9A-Fa-f]{2})$")) {+ std::string item;+ std::stringstream mac = std::stringstream(def.uniq);+ int i = 0;+ while (std::getline(mac, item, ':')) {+ joypad._state->mac_address[i] = std::stoi(item, NULL, 16);+ i = i + 1;+ }+ }
}
auto dev =

[ABeltramo]

@Kishi85 I've just pushed a potential fix for this games-on-whales/inputtino#31

You should be able to just pass the device_uniq property in the canonical MAC address format like AA:00:CC:11:EE:22 and it should fix the matching issue for this issue. The phys shouldn't be needed, I've hardcoded INPUTTINO_BT_LINK if it's empty, but you can pass any String in theory. I don't think any SW relies on that..

I gave that a quick go, and it seems to be working for me, let me know if this fixes it for you too, and I'll merge the PR in inputtino.

[Kishi85]

@Kishi85 I've just pushed a potential fix for this games-on-whales/inputtino#31

You should be able to just pass the device_uniq property in the canonical MAC address format like AA:00:CC:11:EE:22 and it should fix the matching issue for this issue. The phys shouldn't be needed, I've hardcoded INPUTTINO_BT_LINK if it's empty, but you can pass any String in theory. I don't think any SW relies on that..

I gave that a quick go, and it seems to be working for me, let me know if this fixes it for you too, and I'll merge the PR in inputtino.

I've tested it and apart from that remark I left on the PR everything looks good to me and is working. I'm not sure whether I'll remove the device_phys from this PR tho I'll leave device_phys in for now as that is what is shown in dmesg after when the controller connects (otherwise it would show INPUTTINO_BT_LINK instead of the MAC address):

Example: hidraw5: BLUETOOTH HID v81.11 Gamepad [Sunshine PS5 (virtual) pad] on02:00:00:00:00:00

[ABeltramo]

I've tested it and apart from that remark I left on the PR everything looks good to me

You lost me there, which remark are you talking about?

[Kishi85]

I've tested it and apart from that remark I left on the PR everything looks good to me

You lost me there, which remark are you talking about?

My review about making the MAC parser safer by regex matching it beforehand on your PR at games-on-whales/inputtino#31

EDIT: Whoops. Forgot to submit, should be there now.

[Kishi85]

This is ready for merge on my end and @ABeltramo has updated inputtino so that device_uniq does what is necessary for this to fully work now.

Since I haven't worked that much with dependabot so far: Do I have to update the submodule in this PR or will dependabot put up a separate PR for inputtino?

[ReenigneArcher]

We could initialize the device_mac as empty and then set it only if needed, reducing the if/else block.

There's a few lint errors here: https://github.com/LizardByte/Sunshine/actions/runs/16984755077/job/48225412676?pr=4158#step:11:19

Otherwise, looks fine to me.

[Kishi85]

Done as requested. For this to fully work it requires the third-party/inputtino to be bumped to latest stable but i'm assuming dependabot will take care of this.

[ReenigneArcher]

For this to fully work it requires the third-party/inputtino to be bumped to latest stable but i'm assuming dependabot will take care of this.

Yes, dependabot will pick up any changes. Currently it runs daily (M-F), so should pick up on Monday.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Kishi85]

Description

This PR adds an option to change how virtual DS5 controllers are created that allows them to retain controller settings (when stored based on the virtual devices MAC-Address, like Steam does) by disabling the random MAC generation and manually specifiying a private MAC-based on the connected gamepads global index. The behaviour then should be equal to the way XBox- and Switchcontrollers and DS4 on Windows are handled currently.

Screenshot

Issues Fixed or Closed

• ResolvesSunshine virtual Dualsense controller registers with new ids every new session #3404

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[ReenigneArcher]

Thank you for the PR! I just have two comments below.

[codecov]

Bundle Report

Changes will increase total bundle size by 1.29kB (0.07%) ⬆️. This is within the configured threshold ✅

Detailed changes

Bundle name	Size	Change
sunshine-esm	1.75MB	1.29kB (0.07%) ⬆️

Affected Assets, Files, and Routes:

view changes for bundle: sunshine-esm

Assets Changed:

Asset Name	Size Change	Total Size	Change (%)
assets/_plugin-*.js	343 bytes	342.53kB	0.1%
assets/config-*.js	952 bytes	58.75kB	1.65%

[codecov]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 12.46%. Comparing base (7895440) to head (ee38c35).
⚠️ Report is 2 commits behind head on master.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/config.cpp	0.00%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #4158 +/- ##
==========================================
+ Coverage 11.60% 12.46% +0.86% 
==========================================
Files 69 66 -3 Lines 12367 12458 +91 Branches 5862 5758 -104 ==========================================
+ Hits 1435 1553 +118 + Misses 10507 10448 -59 - Partials 425 457 +32 

Flag	Coverage Δ
Linux-AppImage	?
Windows-AMD64	12.46% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/config.h	0.00% <ø> (ø)
src/config.cpp	0.00% <0.00%> (ø)

... and 78 files with indirect coverage changes

[Kishi85]

I've taken the time to test this a bit today and after removing the hex base prefix it is working as intended but the current static mac prefix is not working with Steam the way it should (probably because it is classed as a private mac). I'll do some further testing and probably have to update the used prefix before this can be merged for the desired effect.

EDIT: Further testing shows that with randomized MAC by inputtino the Steam preferences filename matches the generated MAC but with the statically created one it does not work and steam randomizes the config. Could this be a weird string formatting problem?

[ABeltramo]

Thanks for working on this, the PR looks good!
I've tested this locally and I think I see where the issue is: inputtino always generates a random MAC address and that will most likely mess up the matching.

You can easily check the output HID_PHYS and HID_UNIQ using

udevadm monitor -u -p

and hot-plugging the device during a stream.

As a side note, my original comment was kind of wrong.. PHYS is just the "physical path" of the device in the system, such as the USB port or Bluetooth connection. It's most likely not being used for matching, so we can definitely leave that one out. Not sure if HID_PHYS is generated based on a combination of things (including the MAC address?), I'll have to test it better.

I'm going to add something in inputtino that controls the MAC address generation, that's most likely the only thing needed to fix this..

[Kishi85]

Thanks for working on this, the PR looks good! I've tested this locally and I think I see where the issue is: inputtino always generates a random MAC address and that will most likely mess up the matching.

You can easily check the output HID_PHYS and HID_UNIQ using

udevadm monitor -u -p

and hot-plugging the device during a stream.

As a side note, my original comment was kind of wrong.. PHYS is just the "physical path" of the device in the system, such as the USB port or Bluetooth connection. It's most likely not being used for matching, so we can definitely leave that one out. Not sure if HID_PHYS is generated based on a combination of things (including the MAC address?), I'll have to test it better.

I'm going to add something in inputtino that controls the MAC address generation, that's most likely the only thing needed to fix this..

That sounds good as it would simplify things for use-cases like this. You could probably just use the value in device_uniq for the MAC-Address as long as it is valid.

I've seen that the generated mac is also used here and for that call it can't be specified manually. Maybe thats the main culprit?

EDIT: It's used throught the PS5Joypad-Implementation so being able to specify a value upon creation seems to be the only logical way

[Kishi85]

Can confirm that this requires the already mentioned changes to MAC handling in inputtino to work as intended. @ABeltramo I'll keep a look out on the fix on your side and adapt this PR if necessary.

To test this i did a rather quick hack on inputtino that parses back the mac from device_uniq to joypad._state before calling UHID create2 and then it is finally working in Steam. Here's the patch if anybody wants to try it:

diff -ruN a/third-party/inputtino/src/uhid/joypad_ps5.cpp sunshine/third-party/inputtino/src/uhid/joypad_ps5.cpp--- a/third-party/inputtino/src/uhid/joypad_ps5.cpp 2025-08-15 13:00:08.148557490 +0200+++ sunshine/third-party/inputtino/src/uhid/joypad_ps5.cpp 2025-08-15 13:27:51.574081232 +0200@@ -8,6 +8,8 @@
#include <inputtino/input.hpp>
#include <iomanip>
#include <random>
+#include <regex>+#include <sstream>
#include <uhid/protected_types.hpp>
#include <uhid/ps5.hpp>
#include <uhid/uhid.hpp>
@@ -272,6 +274,16 @@
}
if (def.uniq.empty()) {
def.uniq = joypad.get_mac_address();
+ } else {+ if (std::regex_match(def.uniq, (std::regex) "^([0-9A-Fa-f]{2}[:]){5}([0-9A-Fa-f]{2})$")) {+ std::string item;+ std::stringstream mac = std::stringstream(def.uniq);+ int i = 0;+ while (std::getline(mac, item, ':')) {+ joypad._state->mac_address[i] = std::stoi(item, NULL, 16);+ i = i + 1;+ }+ }
}
auto dev =

[ABeltramo]

@Kishi85 I've just pushed a potential fix for this games-on-whales/inputtino#31

You should be able to just pass the device_uniq property in the canonical MAC address format like AA:00:CC:11:EE:22 and it should fix the matching issue for this issue. The phys shouldn't be needed, I've hardcoded INPUTTINO_BT_LINK if it's empty, but you can pass any String in theory. I don't think any SW relies on that..

I gave that a quick go, and it seems to be working for me, let me know if this fixes it for you too, and I'll merge the PR in inputtino.

[Kishi85]

@Kishi85 I've just pushed a potential fix for this games-on-whales/inputtino#31

You should be able to just pass the device_uniq property in the canonical MAC address format like AA:00:CC:11:EE:22 and it should fix the matching issue for this issue. The phys shouldn't be needed, I've hardcoded INPUTTINO_BT_LINK if it's empty, but you can pass any String in theory. I don't think any SW relies on that..

I gave that a quick go, and it seems to be working for me, let me know if this fixes it for you too, and I'll merge the PR in inputtino.

I've tested it and apart from that remark I left on the PR everything looks good to me and is working. I'm not sure whether I'll remove the device_phys from this PR tho I'll leave device_phys in for now as that is what is shown in dmesg after when the controller connects (otherwise it would show INPUTTINO_BT_LINK instead of the MAC address):

Example: hidraw5: BLUETOOTH HID v81.11 Gamepad [Sunshine PS5 (virtual) pad] on02:00:00:00:00:00

[ABeltramo]

I've tested it and apart from that remark I left on the PR everything looks good to me

You lost me there, which remark are you talking about?

[Kishi85]

I've tested it and apart from that remark I left on the PR everything looks good to me

You lost me there, which remark are you talking about?

My review about making the MAC parser safer by regex matching it beforehand on your PR at games-on-whales/inputtino#31

EDIT: Whoops. Forgot to submit, should be there now.

[Kishi85]

This is ready for merge on my end and @ABeltramo has updated inputtino so that device_uniq does what is necessary for this to fully work now.

Since I haven't worked that much with dependabot so far: Do I have to update the submodule in this PR or will dependabot put up a separate PR for inputtino?

[ReenigneArcher]

We could initialize the device_mac as empty and then set it only if needed, reducing the if/else block.

There's a few lint errors here: https://github.com/LizardByte/Sunshine/actions/runs/16984755077/job/48225412676?pr=4158#step:11:19

Otherwise, looks fine to me.

[Kishi85]

Done as requested. For this to fully work it requires the third-party/inputtino to be bumped to latest stable but i'm assuming dependabot will take care of this.

[ReenigneArcher]

For this to fully work it requires the third-party/inputtino to be bumped to latest stable but i'm assuming dependabot will take care of this.

Yes, dependabot will pick up any changes. Currently it runs daily (M-F), so should pick up on Monday.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Kishi85]

Description

This PR adds an option to change how virtual DS5 controllers are created that allows them to retain controller settings (when stored based on the virtual devices MAC-Address, like Steam does) by disabling the random MAC generation and manually specifiying a private MAC-based on the connected gamepads global index. The behaviour then should be equal to the way XBox- and Switchcontrollers and DS4 on Windows are handled currently.

Screenshot

Issues Fixed or Closed

• ResolvesSunshine virtual Dualsense controller registers with new ids every new session #3404

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[ReenigneArcher]

Thank you for the PR! I just have two comments below.

[codecov]

Bundle Report

Changes will increase total bundle size by 1.29kB (0.07%) ⬆️. This is within the configured threshold ✅

Detailed changes

Bundle name	Size	Change
sunshine-esm	1.75MB	1.29kB (0.07%) ⬆️

Affected Assets, Files, and Routes:

view changes for bundle: sunshine-esm

Assets Changed:

Asset Name	Size Change	Total Size	Change (%)
assets/_plugin-*.js	343 bytes	342.53kB	0.1%
assets/config-*.js	952 bytes	58.75kB	1.65%

[codecov]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 12.46%. Comparing base (7895440) to head (ee38c35).
⚠️ Report is 2 commits behind head on master.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/config.cpp	0.00%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #4158 +/- ##
==========================================
+ Coverage 11.60% 12.46% +0.86% 
==========================================
Files 69 66 -3 Lines 12367 12458 +91 Branches 5862 5758 -104 ==========================================
+ Hits 1435 1553 +118 + Misses 10507 10448 -59 - Partials 425 457 +32 

Flag	Coverage Δ
Linux-AppImage	?
Windows-AMD64	12.46% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/config.h	0.00% <ø> (ø)
src/config.cpp	0.00% <0.00%> (ø)

... and 78 files with indirect coverage changes

[Kishi85]

I've taken the time to test this a bit today and after removing the hex base prefix it is working as intended but the current static mac prefix is not working with Steam the way it should (probably because it is classed as a private mac). I'll do some further testing and probably have to update the used prefix before this can be merged for the desired effect.

EDIT: Further testing shows that with randomized MAC by inputtino the Steam preferences filename matches the generated MAC but with the statically created one it does not work and steam randomizes the config. Could this be a weird string formatting problem?

[ABeltramo]

Thanks for working on this, the PR looks good!
I've tested this locally and I think I see where the issue is: inputtino always generates a random MAC address and that will most likely mess up the matching.

You can easily check the output HID_PHYS and HID_UNIQ using

udevadm monitor -u -p

and hot-plugging the device during a stream.

As a side note, my original comment was kind of wrong.. PHYS is just the "physical path" of the device in the system, such as the USB port or Bluetooth connection. It's most likely not being used for matching, so we can definitely leave that one out. Not sure if HID_PHYS is generated based on a combination of things (including the MAC address?), I'll have to test it better.

I'm going to add something in inputtino that controls the MAC address generation, that's most likely the only thing needed to fix this..

[Kishi85]

Thanks for working on this, the PR looks good! I've tested this locally and I think I see where the issue is: inputtino always generates a random MAC address and that will most likely mess up the matching.

You can easily check the output HID_PHYS and HID_UNIQ using

udevadm monitor -u -p

and hot-plugging the device during a stream.

As a side note, my original comment was kind of wrong.. PHYS is just the "physical path" of the device in the system, such as the USB port or Bluetooth connection. It's most likely not being used for matching, so we can definitely leave that one out. Not sure if HID_PHYS is generated based on a combination of things (including the MAC address?), I'll have to test it better.

I'm going to add something in inputtino that controls the MAC address generation, that's most likely the only thing needed to fix this..

That sounds good as it would simplify things for use-cases like this. You could probably just use the value in device_uniq for the MAC-Address as long as it is valid.

I've seen that the generated mac is also used here and for that call it can't be specified manually. Maybe thats the main culprit?

EDIT: It's used throught the PS5Joypad-Implementation so being able to specify a value upon creation seems to be the only logical way

[Kishi85]

Can confirm that this requires the already mentioned changes to MAC handling in inputtino to work as intended. @ABeltramo I'll keep a look out on the fix on your side and adapt this PR if necessary.

To test this i did a rather quick hack on inputtino that parses back the mac from device_uniq to joypad._state before calling UHID create2 and then it is finally working in Steam. Here's the patch if anybody wants to try it:

diff -ruN a/third-party/inputtino/src/uhid/joypad_ps5.cpp sunshine/third-party/inputtino/src/uhid/joypad_ps5.cpp--- a/third-party/inputtino/src/uhid/joypad_ps5.cpp 2025-08-15 13:00:08.148557490 +0200+++ sunshine/third-party/inputtino/src/uhid/joypad_ps5.cpp 2025-08-15 13:27:51.574081232 +0200@@ -8,6 +8,8 @@
#include <inputtino/input.hpp>
#include <iomanip>
#include <random>
+#include <regex>+#include <sstream>
#include <uhid/protected_types.hpp>
#include <uhid/ps5.hpp>
#include <uhid/uhid.hpp>
@@ -272,6 +274,16 @@
}
if (def.uniq.empty()) {
def.uniq = joypad.get_mac_address();
+ } else {+ if (std::regex_match(def.uniq, (std::regex) "^([0-9A-Fa-f]{2}[:]){5}([0-9A-Fa-f]{2})$")) {+ std::string item;+ std::stringstream mac = std::stringstream(def.uniq);+ int i = 0;+ while (std::getline(mac, item, ':')) {+ joypad._state->mac_address[i] = std::stoi(item, NULL, 16);+ i = i + 1;+ }+ }
}
auto dev =

[ABeltramo]

@Kishi85 I've just pushed a potential fix for this games-on-whales/inputtino#31

You should be able to just pass the device_uniq property in the canonical MAC address format like AA:00:CC:11:EE:22 and it should fix the matching issue for this issue. The phys shouldn't be needed, I've hardcoded INPUTTINO_BT_LINK if it's empty, but you can pass any String in theory. I don't think any SW relies on that..

I gave that a quick go, and it seems to be working for me, let me know if this fixes it for you too, and I'll merge the PR in inputtino.

[Kishi85]

@Kishi85 I've just pushed a potential fix for this games-on-whales/inputtino#31

You should be able to just pass the device_uniq property in the canonical MAC address format like AA:00:CC:11:EE:22 and it should fix the matching issue for this issue. The phys shouldn't be needed, I've hardcoded INPUTTINO_BT_LINK if it's empty, but you can pass any String in theory. I don't think any SW relies on that..

I gave that a quick go, and it seems to be working for me, let me know if this fixes it for you too, and I'll merge the PR in inputtino.

I've tested it and apart from that remark I left on the PR everything looks good to me and is working. I'm not sure whether I'll remove the device_phys from this PR tho I'll leave device_phys in for now as that is what is shown in dmesg after when the controller connects (otherwise it would show INPUTTINO_BT_LINK instead of the MAC address):

Example: hidraw5: BLUETOOTH HID v81.11 Gamepad [Sunshine PS5 (virtual) pad] on02:00:00:00:00:00

[ABeltramo]

I've tested it and apart from that remark I left on the PR everything looks good to me

You lost me there, which remark are you talking about?

[Kishi85]

I've tested it and apart from that remark I left on the PR everything looks good to me

You lost me there, which remark are you talking about?

My review about making the MAC parser safer by regex matching it beforehand on your PR at games-on-whales/inputtino#31

EDIT: Whoops. Forgot to submit, should be there now.

[Kishi85]

This is ready for merge on my end and @ABeltramo has updated inputtino so that device_uniq does what is necessary for this to fully work now.

Since I haven't worked that much with dependabot so far: Do I have to update the submodule in this PR or will dependabot put up a separate PR for inputtino?

[ReenigneArcher]

We could initialize the device_mac as empty and then set it only if needed, reducing the if/else block.

There's a few lint errors here: https://github.com/LizardByte/Sunshine/actions/runs/16984755077/job/48225412676?pr=4158#step:11:19

Otherwise, looks fine to me.

[Kishi85]

Done as requested. For this to fully work it requires the third-party/inputtino to be bumped to latest stable but i'm assuming dependabot will take care of this.

[ReenigneArcher]

For this to fully work it requires the third-party/inputtino to be bumped to latest stable but i'm assuming dependabot will take care of this.

Yes, dependabot will pick up any changes. Currently it runs daily (M-F), so should pick up on Monday.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Kishi85]

Description

This PR adds an option to change how virtual DS5 controllers are created that allows them to retain controller settings (when stored based on the virtual devices MAC-Address, like Steam does) by disabling the random MAC generation and manually specifiying a private MAC-based on the connected gamepads global index. The behaviour then should be equal to the way XBox- and Switchcontrollers and DS4 on Windows are handled currently.

Screenshot

Issues Fixed or Closed

• ResolvesSunshine virtual Dualsense controller registers with new ids every new session #3404

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[ReenigneArcher]

Thank you for the PR! I just have two comments below.

[codecov]

Bundle Report

Changes will increase total bundle size by 1.29kB (0.07%) ⬆️. This is within the configured threshold ✅

Detailed changes

Bundle name	Size	Change
sunshine-esm	1.75MB	1.29kB (0.07%) ⬆️

Affected Assets, Files, and Routes:

view changes for bundle: sunshine-esm

Assets Changed:

Asset Name	Size Change	Total Size	Change (%)
assets/_plugin-*.js	343 bytes	342.53kB	0.1%
assets/config-*.js	952 bytes	58.75kB	1.65%

[codecov]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 12.46%. Comparing base (7895440) to head (ee38c35).
⚠️ Report is 2 commits behind head on master.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/config.cpp	0.00%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #4158 +/- ##
==========================================
+ Coverage 11.60% 12.46% +0.86% 
==========================================
Files 69 66 -3 Lines 12367 12458 +91 Branches 5862 5758 -104 ==========================================
+ Hits 1435 1553 +118 + Misses 10507 10448 -59 - Partials 425 457 +32 

Flag	Coverage Δ
Linux-AppImage	?
Windows-AMD64	12.46% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/config.h	0.00% <ø> (ø)
src/config.cpp	0.00% <0.00%> (ø)

... and 78 files with indirect coverage changes

[Kishi85]

I've taken the time to test this a bit today and after removing the hex base prefix it is working as intended but the current static mac prefix is not working with Steam the way it should (probably because it is classed as a private mac). I'll do some further testing and probably have to update the used prefix before this can be merged for the desired effect.

EDIT: Further testing shows that with randomized MAC by inputtino the Steam preferences filename matches the generated MAC but with the statically created one it does not work and steam randomizes the config. Could this be a weird string formatting problem?

[ABeltramo]

Thanks for working on this, the PR looks good!
I've tested this locally and I think I see where the issue is: inputtino always generates a random MAC address and that will most likely mess up the matching.

You can easily check the output HID_PHYS and HID_UNIQ using

udevadm monitor -u -p

and hot-plugging the device during a stream.

As a side note, my original comment was kind of wrong.. PHYS is just the "physical path" of the device in the system, such as the USB port or Bluetooth connection. It's most likely not being used for matching, so we can definitely leave that one out. Not sure if HID_PHYS is generated based on a combination of things (including the MAC address?), I'll have to test it better.

I'm going to add something in inputtino that controls the MAC address generation, that's most likely the only thing needed to fix this..

[Kishi85]

Thanks for working on this, the PR looks good! I've tested this locally and I think I see where the issue is: inputtino always generates a random MAC address and that will most likely mess up the matching.

You can easily check the output HID_PHYS and HID_UNIQ using

udevadm monitor -u -p

and hot-plugging the device during a stream.

As a side note, my original comment was kind of wrong.. PHYS is just the "physical path" of the device in the system, such as the USB port or Bluetooth connection. It's most likely not being used for matching, so we can definitely leave that one out. Not sure if HID_PHYS is generated based on a combination of things (including the MAC address?), I'll have to test it better.

I'm going to add something in inputtino that controls the MAC address generation, that's most likely the only thing needed to fix this..

That sounds good as it would simplify things for use-cases like this. You could probably just use the value in device_uniq for the MAC-Address as long as it is valid.

I've seen that the generated mac is also used here and for that call it can't be specified manually. Maybe thats the main culprit?

EDIT: It's used throught the PS5Joypad-Implementation so being able to specify a value upon creation seems to be the only logical way

[Kishi85]

Can confirm that this requires the already mentioned changes to MAC handling in inputtino to work as intended. @ABeltramo I'll keep a look out on the fix on your side and adapt this PR if necessary.

To test this i did a rather quick hack on inputtino that parses back the mac from device_uniq to joypad._state before calling UHID create2 and then it is finally working in Steam. Here's the patch if anybody wants to try it:

diff -ruN a/third-party/inputtino/src/uhid/joypad_ps5.cpp sunshine/third-party/inputtino/src/uhid/joypad_ps5.cpp--- a/third-party/inputtino/src/uhid/joypad_ps5.cpp 2025-08-15 13:00:08.148557490 +0200+++ sunshine/third-party/inputtino/src/uhid/joypad_ps5.cpp 2025-08-15 13:27:51.574081232 +0200@@ -8,6 +8,8 @@
#include <inputtino/input.hpp>
#include <iomanip>
#include <random>
+#include <regex>+#include <sstream>
#include <uhid/protected_types.hpp>
#include <uhid/ps5.hpp>
#include <uhid/uhid.hpp>
@@ -272,6 +274,16 @@
}
if (def.uniq.empty()) {
def.uniq = joypad.get_mac_address();
+ } else {+ if (std::regex_match(def.uniq, (std::regex) "^([0-9A-Fa-f]{2}[:]){5}([0-9A-Fa-f]{2})$")) {+ std::string item;+ std::stringstream mac = std::stringstream(def.uniq);+ int i = 0;+ while (std::getline(mac, item, ':')) {+ joypad._state->mac_address[i] = std::stoi(item, NULL, 16);+ i = i + 1;+ }+ }
}
auto dev =

[ABeltramo]

@Kishi85 I've just pushed a potential fix for this games-on-whales/inputtino#31

You should be able to just pass the device_uniq property in the canonical MAC address format like AA:00:CC:11:EE:22 and it should fix the matching issue for this issue. The phys shouldn't be needed, I've hardcoded INPUTTINO_BT_LINK if it's empty, but you can pass any String in theory. I don't think any SW relies on that..

I gave that a quick go, and it seems to be working for me, let me know if this fixes it for you too, and I'll merge the PR in inputtino.

[Kishi85]

@Kishi85 I've just pushed a potential fix for this games-on-whales/inputtino#31

You should be able to just pass the device_uniq property in the canonical MAC address format like AA:00:CC:11:EE:22 and it should fix the matching issue for this issue. The phys shouldn't be needed, I've hardcoded INPUTTINO_BT_LINK if it's empty, but you can pass any String in theory. I don't think any SW relies on that..

I gave that a quick go, and it seems to be working for me, let me know if this fixes it for you too, and I'll merge the PR in inputtino.

I've tested it and apart from that remark I left on the PR everything looks good to me and is working. I'm not sure whether I'll remove the device_phys from this PR tho I'll leave device_phys in for now as that is what is shown in dmesg after when the controller connects (otherwise it would show INPUTTINO_BT_LINK instead of the MAC address):

Example: hidraw5: BLUETOOTH HID v81.11 Gamepad [Sunshine PS5 (virtual) pad] on02:00:00:00:00:00

[ABeltramo]

I've tested it and apart from that remark I left on the PR everything looks good to me

You lost me there, which remark are you talking about?

[Kishi85]

I've tested it and apart from that remark I left on the PR everything looks good to me

You lost me there, which remark are you talking about?

My review about making the MAC parser safer by regex matching it beforehand on your PR at games-on-whales/inputtino#31

EDIT: Whoops. Forgot to submit, should be there now.

[Kishi85]

This is ready for merge on my end and @ABeltramo has updated inputtino so that device_uniq does what is necessary for this to fully work now.

Since I haven't worked that much with dependabot so far: Do I have to update the submodule in this PR or will dependabot put up a separate PR for inputtino?

[ReenigneArcher]

We could initialize the device_mac as empty and then set it only if needed, reducing the if/else block.

There's a few lint errors here: https://github.com/LizardByte/Sunshine/actions/runs/16984755077/job/48225412676?pr=4158#step:11:19

Otherwise, looks fine to me.

[Kishi85]

Done as requested. For this to fully work it requires the third-party/inputtino to be bumped to latest stable but i'm assuming dependabot will take care of this.

[ReenigneArcher]

For this to fully work it requires the third-party/inputtino to be bumped to latest stable but i'm assuming dependabot will take care of this.

Yes, dependabot will pick up any changes. Currently it runs daily (M-F), so should pick up on Monday.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Kishi85]

Description

This PR adds an option to change how virtual DS5 controllers are created that allows them to retain controller settings (when stored based on the virtual devices MAC-Address, like Steam does) by disabling the random MAC generation and manually specifiying a private MAC-based on the connected gamepads global index. The behaviour then should be equal to the way XBox- and Switchcontrollers and DS4 on Windows are handled currently.

Screenshot

Issues Fixed or Closed

• ResolvesSunshine virtual Dualsense controller registers with new ids every new session #3404

Roadmap Issues

Type of Change

• feat: New feature (non-breaking change which adds functionality)
• fix: Bug fix (non-breaking change which fixes an issue)
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semicolons, etc.)
• refactor: Code change that neither fixes a bug nor adds a feature
• perf: Code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies
• ci: Changes to CI configuration files and scripts
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit
• BREAKING CHANGE: Introduces a breaking change (can be combined with any type above)

Checklist

• Code follows the style guidelines of this project
• Code has been self-reviewed
• Code has been commented, particularly in hard-to-understand areas
• Code docstring/documentation-blocks for new or existing methods/components have been added or updated
• Unit tests have been added or updated for any new or modified functionality

AI Usage

• None: No AI tools were used in creating this PR
• Light: AI provided minor assistance (formatting, simple suggestions)
• Moderate: AI helped with code generation or debugging specific parts
• Heavy: AI generated most or all of the code changes

[ReenigneArcher]

Thank you for the PR! I just have two comments below.

[codecov]

Bundle Report

Changes will increase total bundle size by 1.29kB (0.07%) ⬆️. This is within the configured threshold ✅

Detailed changes

Bundle name	Size	Change
sunshine-esm	1.75MB	1.29kB (0.07%) ⬆️

Affected Assets, Files, and Routes:

view changes for bundle: sunshine-esm

Assets Changed:

Asset Name	Size Change	Total Size	Change (%)
assets/_plugin-*.js	343 bytes	342.53kB	0.1%
assets/config-*.js	952 bytes	58.75kB	1.65%

[codecov]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 12.46%. Comparing base (7895440) to head (ee38c35).
⚠️ Report is 2 commits behind head on master.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/config.cpp	0.00%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@## master #4158 +/- ##
==========================================
+ Coverage 11.60% 12.46% +0.86% 
==========================================
Files 69 66 -3 Lines 12367 12458 +91 Branches 5862 5758 -104 ==========================================
+ Hits 1435 1553 +118 + Misses 10507 10448 -59 - Partials 425 457 +32 

Flag	Coverage Δ
Linux-AppImage	?
Windows-AMD64	12.46% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/config.h	0.00% <ø> (ø)
src/config.cpp	0.00% <0.00%> (ø)

... and 78 files with indirect coverage changes

[Kishi85]

I've taken the time to test this a bit today and after removing the hex base prefix it is working as intended but the current static mac prefix is not working with Steam the way it should (probably because it is classed as a private mac). I'll do some further testing and probably have to update the used prefix before this can be merged for the desired effect.

EDIT: Further testing shows that with randomized MAC by inputtino the Steam preferences filename matches the generated MAC but with the statically created one it does not work and steam randomizes the config. Could this be a weird string formatting problem?

[ABeltramo]

Thanks for working on this, the PR looks good!
I've tested this locally and I think I see where the issue is: inputtino always generates a random MAC address and that will most likely mess up the matching.

You can easily check the output HID_PHYS and HID_UNIQ using

udevadm monitor -u -p

and hot-plugging the device during a stream.

As a side note, my original comment was kind of wrong.. PHYS is just the "physical path" of the device in the system, such as the USB port or Bluetooth connection. It's most likely not being used for matching, so we can definitely leave that one out. Not sure if HID_PHYS is generated based on a combination of things (including the MAC address?), I'll have to test it better.

I'm going to add something in inputtino that controls the MAC address generation, that's most likely the only thing needed to fix this..

[Kishi85]

Thanks for working on this, the PR looks good! I've tested this locally and I think I see where the issue is: inputtino always generates a random MAC address and that will most likely mess up the matching.

You can easily check the output HID_PHYS and HID_UNIQ using

udevadm monitor -u -p

and hot-plugging the device during a stream.

As a side note, my original comment was kind of wrong.. PHYS is just the "physical path" of the device in the system, such as the USB port or Bluetooth connection. It's most likely not being used for matching, so we can definitely leave that one out. Not sure if HID_PHYS is generated based on a combination of things (including the MAC address?), I'll have to test it better.

I'm going to add something in inputtino that controls the MAC address generation, that's most likely the only thing needed to fix this..

That sounds good as it would simplify things for use-cases like this. You could probably just use the value in device_uniq for the MAC-Address as long as it is valid.

I've seen that the generated mac is also used here and for that call it can't be specified manually. Maybe thats the main culprit?

EDIT: It's used throught the PS5Joypad-Implementation so being able to specify a value upon creation seems to be the only logical way

[Kishi85]

Can confirm that this requires the already mentioned changes to MAC handling in inputtino to work as intended. @ABeltramo I'll keep a look out on the fix on your side and adapt this PR if necessary.

To test this i did a rather quick hack on inputtino that parses back the mac from device_uniq to joypad._state before calling UHID create2 and then it is finally working in Steam. Here's the patch if anybody wants to try it:

diff -ruN a/third-party/inputtino/src/uhid/joypad_ps5.cpp sunshine/third-party/inputtino/src/uhid/joypad_ps5.cpp--- a/third-party/inputtino/src/uhid/joypad_ps5.cpp 2025-08-15 13:00:08.148557490 +0200+++ sunshine/third-party/inputtino/src/uhid/joypad_ps5.cpp 2025-08-15 13:27:51.574081232 +0200@@ -8,6 +8,8 @@
#include <inputtino/input.hpp>
#include <iomanip>
#include <random>
+#include <regex>+#include <sstream>
#include <uhid/protected_types.hpp>
#include <uhid/ps5.hpp>
#include <uhid/uhid.hpp>
@@ -272,6 +274,16 @@
}
if (def.uniq.empty()) {
def.uniq = joypad.get_mac_address();
+ } else {+ if (std::regex_match(def.uniq, (std::regex) "^([0-9A-Fa-f]{2}[:]){5}([0-9A-Fa-f]{2})$")) {+ std::string item;+ std::stringstream mac = std::stringstream(def.uniq);+ int i = 0;+ while (std::getline(mac, item, ':')) {+ joypad._state->mac_address[i] = std::stoi(item, NULL, 16);+ i = i + 1;+ }+ }
}
auto dev =

[ABeltramo]

@Kishi85 I've just pushed a potential fix for this games-on-whales/inputtino#31

You should be able to just pass the device_uniq property in the canonical MAC address format like AA:00:CC:11:EE:22 and it should fix the matching issue for this issue. The phys shouldn't be needed, I've hardcoded INPUTTINO_BT_LINK if it's empty, but you can pass any String in theory. I don't think any SW relies on that..

I gave that a quick go, and it seems to be working for me, let me know if this fixes it for you too, and I'll merge the PR in inputtino.

[Kishi85]

@Kishi85 I've just pushed a potential fix for this games-on-whales/inputtino#31

You should be able to just pass the device_uniq property in the canonical MAC address format like AA:00:CC:11:EE:22 and it should fix the matching issue for this issue. The phys shouldn't be needed, I've hardcoded INPUTTINO_BT_LINK if it's empty, but you can pass any String in theory. I don't think any SW relies on that..

I gave that a quick go, and it seems to be working for me, let me know if this fixes it for you too, and I'll merge the PR in inputtino.

I've tested it and apart from that remark I left on the PR everything looks good to me and is working. I'm not sure whether I'll remove the device_phys from this PR tho I'll leave device_phys in for now as that is what is shown in dmesg after when the controller connects (otherwise it would show INPUTTINO_BT_LINK instead of the MAC address):

Example: hidraw5: BLUETOOTH HID v81.11 Gamepad [Sunshine PS5 (virtual) pad] on02:00:00:00:00:00

[ABeltramo]

I've tested it and apart from that remark I left on the PR everything looks good to me

You lost me there, which remark are you talking about?

[Kishi85]

I've tested it and apart from that remark I left on the PR everything looks good to me

You lost me there, which remark are you talking about?

My review about making the MAC parser safer by regex matching it beforehand on your PR at games-on-whales/inputtino#31

EDIT: Whoops. Forgot to submit, should be there now.

[Kishi85]

This is ready for merge on my end and @ABeltramo has updated inputtino so that device_uniq does what is necessary for this to fully work now.

Since I haven't worked that much with dependabot so far: Do I have to update the submodule in this PR or will dependabot put up a separate PR for inputtino?

[ReenigneArcher]

We could initialize the device_mac as empty and then set it only if needed, reducing the if/else block.

There's a few lint errors here: https://github.com/LizardByte/Sunshine/actions/runs/16984755077/job/48225412676?pr=4158#step:11:19

Otherwise, looks fine to me.

[Kishi85]

Done as requested. For this to fully work it requires the third-party/inputtino to be bumped to latest stable but i'm assuming dependabot will take care of this.

[ReenigneArcher]

For this to fully work it requires the third-party/inputtino to be bumped to latest stable but i'm assuming dependabot will take care of this.

Yes, dependabot will pick up any changes. Currently it runs daily (M-F), so should pick up on Monday.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud