Arch Linux

This is also the case for me. Using the rules provided by the steam package does not work. Controller does nothing, doesn't work in overlay, won't pair.

Using the rules provided as a previous workaround:

SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666"
KERNEL=="uinput", MODE="0660", GROUP="myusername", OPTIONS+="static_node=uinput"

works fine.

It works fine here. The "uaccess" tag should be enough. See [1] for an explanation.

[1] https://wiki.archlinux.org/index.php/Talk:Gamepad#Steam_controller_udev_rules

Hmm.. I noticed that by default the mask on /dev/uinput might mess up the permissions.
Does it work after you run the following?
# setfacl -m mask::rwx /dev/uinput

>Does it work after you run the following?
># setfacl -m mask::rwx /dev/uinput

Nope, no difference. Controller not recognised (even by steam).

People seem to be having varying trouble with this. For some the rules supplied with the steam package work fine. Some get keyboard emulation but not controller emulation. Some (including me) get nothing at all.

One important observation for me:

if using package udev rules (tag+=uinput only no group) then /dev/input/js0 and /dev/input/event21 are NOT created.

The only visible permissions difference I could see with getfacl was that group is --- with the steam rules whereas my custom workaround rules gave rw to users group.

Changing the MODE to 0666 make it work here:

< SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666", TAG+="uaccess"
---
> SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0660", TAG+="uaccess"

I received my Steam controller yesterday and it wasn't recognised either. Changing the mode to "0666" worked for me, the controller is now recognised and works flawless.

Looks like a regression from https://bugs.archlinux.org/task/46752

I had this same problem, and changing mode to "0666" worked for me as well. Is there any downside to this fix, and is there any chance of it being included in the steam package?

It was changed from 666 to 660 because of .

Affects me as well. Is there really nobody who has figured out a real fix (not changing MODE to 0666) yet? :/

I bought a steam controller recently and was having issues with the udev rule for it working as well.
From what I can tell the rule provided in the [steam] 1.0.0.51-1 package does work but is too late in the priority.

When using the rule provided in /usr/lib/udev/rules.d/80-steam-controller-permission.rules the first connection of the controller will work. However after turning off the controller and turning it back on it will partially work.
The /dev/input/js0 and corresponding /dev/input/event* won't be created so controller emulation in game will fail to function.

After renaming that rule file from 80-steam-controller-permission.rules to 70-steam-controller-permission.rules it seems to work fully for me. Even after turning off the controller and turning it back on multiple times it will continue to work properly for me having raised the priority of the rule. The /dev/input/js0 and corresponding /dev/input/event* gets created.

Having fiddled around some more with the file name of the rule I've found that it continues to work at a 72-steam-controller-permission.rules and fails at a 73-steam-controller.rules. I don't understand enough about udev rules to know why this is the case. Yet it seems to be a rule loading priority issue.

Good spotting Jack. It seems the problem is this rule is being sourced after uaccess is done by 73-seat-late.rules. This rule should really have a priority 40 to 50, also the MODE=0660 is redundant as that's the default so can be left out too.

I also don't really know how udev works, but on one of my systems the vanilla udev rule (priority 80) works fine, but only if I restart the system with the dongle plugged in.

I don't know how udev really works, but it really seems that 73-seat-late.rules is culprit...
It has this line:
TAG=="uaccess", ENV{MAJOR}!="", RUN{builtin}+="uaccess"

According to this:
http://man7.org/linux/man-pages/man7/udev.7.html
it says that
RUN{type}
Add a program to the list of programs to be executed after
processing all the rules for a specific event, depending on
"type":
"program"
...
"builtin"
As program, but use one of the built-in programs rather than
an external one.


Then, I searched RUN{builtin}+="uaccess" and the first result was:
https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-uaccess.c

So, maybe, after 73-seat-late, all the uaccess tags don't work anymore...

This file is owned by systemd and in the C source file I linked before it explicitly check if logind is running (line 43) otherwise it returns...
@Max do you have systemd and logind installed and enabled?
If not, maybe that's the reason the rule works correctly with a priority of 80.

PS: Sorry for my english...

The problem spotted by Jack is the issue, right? Could this problem be fixed? It's kind of annoying.

Why is this not moving forward? Shouldn't the fix be straight-forward now?

, and are all the same.

Right now the controller is working perfectly fine when it was plugged in before booting. As explains, this is because the uaccess tag is applied by udev rules after it is consumed by the logind udev rule. Since the tag would usually be applied before the rule before logind starts, the controller works fine after boot, but not, for hotpluggin or suspend/resume cycles.

The correct solution would indeed be moving the steam controller udev rule priority to 70 and not as the other bugs suggest to change the mode or use a special steam controllers group for this. This ensure that the uaccess tag mechanic is in use (acl based access rights to the user whose session is active according to logind).

Just a note: both Ubuntu[1] and Debian[2] now use 0666 permissions.

[1] http://packages.ubuntu.com/xenial/steam
[2] https://packages.debian.org/sid/steam-devices

So a few weeks ago a Steam update broke the priority change workaround it seems. I'm using the 0666 workaround now, although I'm not particularily happy with it...

For me the controller does not even work properly if booting "regularly". It does sometimes, sometimes it doesn't.

I seem to get an effective permission of --- on /dev/uinput due to being masked to ---, for a reason I didn't figure out yet.

My steam controller also stopped working with a recent update. Had to do the 0666 trick to fix it. I tried changing the priority to 70 with no effect.