Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#47330 - [steam] Steam Controller rules not working anymore

Attached to Project: Community Packages
Opened by TesX (tesfabpel) - Friday, 11 December 2015, 08:22 GMT
Last edited by Levente Polyak (anthraxx) - Monday, 05 December 2016, 22:53 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Daniel Wallace (gtmanfred)
Levente Polyak (anthraxx)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 8
Private No


The steam package (version provides the steamcontroller's udev rules on its own.
Anyway (at least for me), they don't work anymore...

The controller gets connected to the receiver but Steam can't detect it (even pairing, doesn't work anymore).

I tried installing python-steamcontroller-git from AUR and then launching but it didn't work...
Then I tried running it with sudo and it was running fine...
This task depends upon

Closed by  Levente Polyak (anthraxx)
Monday, 05 December 2016, 22:53 GMT
Reason for closing:  Duplicate
Additional comments about closing:   FS#46752 
Comment by uo ou (uoou) - Sunday, 13 December 2015, 05:24 GMT
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.
Comment by Sebastiaan Lokhorst (lonaowna) - Sunday, 13 December 2015, 12:32 GMT
It works fine here. The "uaccess" tag should be enough. See [1] for an explanation.

Comment by Sebastiaan Lokhorst (lonaowna) - Sunday, 13 December 2015, 12:53 GMT
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
Comment by uo ou (uoou) - Sunday, 13 December 2015, 13:04 GMT
>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.
Comment by Ales Katona (almindor) - Tuesday, 15 December 2015, 15:59 GMT
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.
Comment by Javier Jardón (jjardon) - Monday, 21 December 2015, 00:33 GMT
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"
Comment by Fritz Schrogl (maerowinger) - Thursday, 24 December 2015, 11:04 GMT
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
Comment by Aidan E. (aereaux) - Friday, 08 January 2016, 06:00 GMT
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?
Comment by Sebastiaan Lokhorst (lonaowna) - Friday, 08 January 2016, 09:14 GMT
It was changed from 666 to 660 because of  FS#46825 .
Comment by Jonas Platte (jP_wanN) - Wednesday, 13 January 2016, 20:22 GMT
Affects me as well. Is there really nobody who has figured out a real fix (not changing MODE to 0666) yet? :/
Comment by Jack (JaqFrost) - Monday, 18 January 2016, 16:59 GMT
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] 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.
Comment by James Duley (parched) - Monday, 18 January 2016, 22:13 GMT
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.
Comment by Max (silverhammermba) - Tuesday, 19 January 2016, 03:59 GMT
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.
Comment by TesX (tesfabpel) - Tuesday, 19 January 2016, 07:57 GMT
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:
it says that
Add a program to the list of programs to be executed after
processing all the rules for a specific event, depending on
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:

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...
Comment by Aidan E. (aereaux) - Friday, 06 May 2016, 02:36 GMT
The problem spotted by Jack is the issue, right? Could this problem be fixed? It's kind of annoying.
Comment by Jonas Platte (jP_wanN) - Thursday, 09 June 2016, 12:20 GMT
Why is this not moving forward? Shouldn't the fix be straight-forward now?
Comment by Jan (medhefgo) - Friday, 08 July 2016, 12:58 GMT
 FS#49926 ,  FS#47330  and  FS#46752  are all the same.

Right now the controller is working perfectly fine when it was plugged in before booting. As FS#47995 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).
Comment by Sebastiaan Lokhorst (lonaowna) - Friday, 09 September 2016, 12:57 GMT
Just a note: both Ubuntu[1] and Debian[2] now use 0666 permissions.

Comment by Jonas Platte (jP_wanN) - Saturday, 22 October 2016, 22:06 GMT
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...
Comment by Georg Grabler (STiAT) - Monday, 07 November 2016, 00:19 GMT
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.
Comment by Max (silverhammermba) - Thursday, 01 December 2016, 04:31 GMT
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.