Hmm I actually also need MODE="0666" on that rule to get my steam controller to work. Otherwise /dev/uinput is only accessible to root. Not sure how it worked previously though, kinda odd.

For reference, this is all I need to get my steam controller working correctly in all cases (I know of): https://github.com/Infinisil/system/blob/dadd7a397739a2f18fdc49478efe0f17cb4bc7e0/config/new-modules/gaming.nix#L11-L15

I am not sure why because the uaccess tag should add an ACL on /dev/uinput for the current user

@nyanloutre Oh actually I saw the indication for it having some ACL stuff, but didn't look into what it was. I'll look into it this evening when I have access to my gaming pc.

@infinisil you could try getfacl /dev/uinput without your chmod to see if your user is in the list

@infinisil Hi ! Did you have time to review this ?

Aha! So @cleverca22 figured out that you need to

sudo rmmod uinput
sudo modprobe uinput

to reload uinput such that the change in this PR gets applied properly. After that my steam controller seems to work well without my other hacks.

I'm still a bit confused, because I undid the PR change again and rebuilt, reloaded uinput, but I still have the ACL's now.

Now we can either do this fix in the steam package itself, or we can use the new hardware.steam-hardware.enable option to fix the udev rule via services.udev.extraRules. I think I'd prefer the latter, such that we can keep steam unchanged from upstream.

Did you already test this ?

services.udev.extraRules = ''
  KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", OPTIONS+="static_node=uinput"
'';

I don't have the time to test it right now, so I don't know how it will react when the nearly same rule is already defined in another udev rule file.

But I agree that we could let the Steam package untouched and add this rule in the steam-hardware module

@nyanloutre Well I can't really test this because the ACL's now persist even if I have neither this PR or that line. Maybe I need to reboot?

But I'm 99% sure that

services.udev.extraRules = ''
  KERNEL=="uinput", SUBSYSTEM=="misc", OPTIONS+="static_node=uinput"
'';

should work. All matching udev rules just get applied at the same time and the += operator does the adding thing.

Okay, so this PR doesn't fix it for me. After rebooting, permissions on /dev/uinput are back to normal and I can't use the controller. Rebooting certainly has an influence, which isn't very good, but I'm not sure why.

This is really strange, I am using the unstable channel patched with only this commit and the Steam Controller is working as expected.

Does using an extraRule work for you ?

Hi @infinisil did you had time to investigate further ?

Hi sorry, haven't done that. My reboots are really really slow so I try to avoid them whenever I can, and to debug this (figure out why this udev stuff sometimes only applies after reboot) it seems that I'll have to reboot a couple times :/

I'll look into this eventually, once I have more time and motivation. I wouldn't mind somebody else taking a look at this too.

I tried to reboot multiple time with and without this patch and I get consistent results. If I change it to make it use extraRules would it be OK to merge ?

As long as it consistently solves at least one problem (your xbox controller in this case), I'm okay with merging it, assuming upstream won't fix it. My steam controller might require some more tuning in the future. Yeah I'd prefer extraRules

I am also using a Steam controller, I was mentioning an xbox360 gamepad because the uinput device is used to emulate one

Hello, this patch should be fine as the udev rule files are under an MIT license now : https://github.com/ValveSoftware/steam-devices

Please see #66916