I have a fedora server running sway and sunshine. I’m having a problem where this rule (https://github.com/LizardByte/Sunshine/blob/8765bbf050a18dcaf441851e5e52505a6c709c48/src_assets/linux/misc/60-sunshine.rules) isn’t firing, so the controller stays with root permissions instead of belonging to the input group and it messes things up. I’m not sure why it wont fire that rule.
What if you remove the
ATTRS{name}=="Sunshine PS5 (virtual) pad"conditions? The rules seem to be about virtual controllers that would be created by Sunshine. Not about the physical controller itself.The virtual controller is the problem. The physical controller never plugs into the host.
You’re having a problem with Sunshine. The udev rules work fine, because the controller is officially supported in the kernel. If it’s detected, it’s working fine.
If it’s NOT working with Sunshine involved, that’s a Sunshine problem.
Test with the calibration tools of your DE, and also under Steam. If everything works everywhere else, it’s not udev which is only responsible for detecting and capturing the device input.
If you think it’s a group problem, then…just…add your user to the group maybe?
there is no DE. it’s just headless sway. it works outside steam and steam games but steam stuff wont map correctly. manually setting the group for /dev/hidraw0 to :input fixes the issue temporarily, but its not connected directly to the host. So I need this rule to fire and put this device into the input group when it appears as it is appears within the sessions, not as a directly connected device.
User is already in the input group. But the device is root:root. When I manually set the group to input it works but the device disappears at the end of the session and is recreated when the clients connect in again
The inputs are sent as they are received on the host is the point. There is no transcoding of the HID inputs.
It’s a Sunshine problem.
No, steam accesses the controller differently then say retroarch does. To demonstrate this, if I connect to a session and chown hidraw0 (the device that steam grabs onto) to group input, which the user is in, it’s fine. It works perfectly. Left alone, not all options are exposed in steam and many buttons are improperly assigned.
Kid…look. You keep coming back here and asking this same question, and when people give you very specific answers you keep saying “Nuh-uh, cuzz…”.
You’re missing the point entirely, and you don’t want to listen. If everyone here is so stupid, then why are you here?
Im not seeing “very specific answers.” Where are these? Please quote one.
When I told you udev rules aren’t the problem. Now you’re trying to make it seem like Steam is a problem? What in the world…🤦
no, steam is the symptom because it only happens in steam and steam games. changing the permissions on /dev/hidraw0 fixes that, but that device is destroyed after each session and recreated on new sessions, so manually assigning a group isnt viable.
