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#46752 - [steam] steam controller not detected properly

Attached to Project: Community Packages
Opened by Jerome (sinatosk) - Friday, 16 October 2015, 13:53 GMT
Last edited by Levente Polyak (anthraxx) - Monday, 19 December 2016, 00:55 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To 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 controller is not detected properly by steam client due to udev rules

Steps to reproduce:
- plug controller in
- lsusb shows the controller or dongle is plugged in
- controller can be used but not correctly

My solution was to add a file called "99-steam-controller-permission.rules" at "/etc/lib/udev/rules.d" containing

#USB devices
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666"

add this part of the steam package and store it at "/usr/lib/udev/rules.d" instead
This task depends upon

Closed by  Levente Polyak (anthraxx)
Monday, 19 December 2016, 00:55 GMT
Reason for closing:  Fixed
Additional comments about closing:
Comment by Joseph Knockenhauer (JoeLithium) - Friday, 16 October 2015, 20:37 GMT
I think under solution you mean /usr/bin/udev/rules.d not /etc/lib/udev/rules.d (for some reason my fingers start to automatically type /etc/ also.)
Comment by Daniel Wallace (gtmanfred) - Friday, 16 October 2015, 20:39 GMT
Well, he put it in etc, because it isn't in the package.

The real solution is for the package to have it in /usr, but for a work around now, you put it in /etc/. Same with systemd service units that you make, you put those in /etc/, until a package provdies it in /usr.
Comment by Jerome (sinatosk) - Friday, 16 October 2015, 20:42 GMT
JoeLithium.... if you read my "Suggestion:" I did say "/usr/lib" and not "/usr/bin" or "/etc/lib"

I made mistake in my original post it was suppose to be "/etc/udev/rules.d" not "/etc/lib/udev/rules.d"

It's recommended to use "etc" instead of "lib" when not used as a package
Comment by Joseph Knockenhauer (JoeLithium) - Friday, 16 October 2015, 20:46 GMT
I have started in on the after work beer a little to hard and early. I understand now you are completely correct. My apologies!
Comment by Daniel Wallace (gtmanfred) - Friday, 16 October 2015, 20:55 GMT
I am soon to be right behind you :P

I am going to be clearing out all my bugs tomorrow
Comment by Peter Severin Rasmussen (PeterSR) - Sunday, 18 October 2015, 07:42 GMT
The solution using "/etc/udev/rules.d" worked for me as well.
But my Steam window would then block, giving me the classic "do-dong" sound every time I hovered the cursor over it.
Turning the controller on and waiting a few moments fixed this for me.
Comment by Lev Lybin (lybin) - Friday, 01 April 2016, 15:03 GMT
  • Field changed: Percent Complete (100% → 0%)
The problem is relevant for me.

Steam Controller known issues and platform-specific notes:
The controller is fully supported on Linux without needing a kernel driver, but Steam needs proper read-write access to the HID device nodes it exposes in order to program it. We are working with distributions to make sure the necessary access is provided out of the box, but this might not currently be the case depending on your distribution of choice. Here are the rules needed for proper use of the controller:
# This rule is needed for basic functionality of the controller in Steam and keyboard/mouse emulation
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666"

# This rule is necessary for gamepad emulation; make sure you replace 'pgriffais' with a group that the user that runs Steam belongs to
KERNEL=="uinput", MODE="0660", GROUP="pgriffais", OPTIONS+="static_node=uinput"


If change the MODE from MODE="0660"(in arch steam package) to MODE="0666"(from article) - works well.

And, I think, can add GROUP="pgriffais", but change name on "games". The group "games" is exists in arch.

And, see please on a files in the package, have some other difference:
Comment by Saturnino Garcia (elsaturnino) - Sunday, 03 April 2016, 20:35 GMT
As is, the steam controller is recognized and works while steam is running.

However, the controller isn't recognized in games unless you make changes to the MODE. I set MODE to "0666" in the SUBSYSTEM line and added another MODE entry (set to "0660") in the KERNEL line. I also added a GROUP (set to "users" in my case), but I'm not sure that was an important step.
Comment by Lev Lybin (lybin) - Monday, 04 April 2016, 05:29 GMT
Yes, I agree with you completely.
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 Levente Polyak (anthraxx) - Friday, 08 July 2016, 13:28 GMT
@medhefgo: please only post the very same text once. will be handled. thanks
Comment by Joe Balough (scallopedllama) - Wednesday, 21 September 2016, 21:48 GMT
I followed Jan's suggestion and copied the system-provided steam-controller-permissions.rules file from /usr/lib/udev/rules.d into /etc/udev/rules.d with the 70 priority and my Steam Controller works now after a reboot.

sudo cp /usr/lib/udev/rules.d/80-steam-controller-permission.rules /etc/udev/rules.d/70-steam-controller-permission.rules

I was having trouble using it with streaming from my Steam Link, even. This sounds like the correct solution to the problem to me.
Comment by TesX (tesfabpel) - Monday, 03 October 2016, 18:09 GMT
Moving the rule to priority 70 seems to work fine to me...
Just for testing I did:
mv 80-steam-controller-permission.rules 70-steam-controller-permission.rules
Comment by Yao Mitachi (yaomtc) - Sunday, 16 October 2016, 04:13 GMT
Has anyone successfully updated a new Steam Controller's firmware from in Arch Linux lately? I've been completely unable to get this working, no matter what I try. Posted a thread here:

Got some assistance from a Valve employee here, but I guess he can only spend so much time trying to help someone on a technically unsupported operating system. (It's not Ubuntu/SteamOS after all.)
Comment by Lev Lybin (lybin) - Sunday, 16 October 2016, 17:31 GMT
I use my build and still to works fine, can see inside PKGBUILD:
Comment by Yao Mitachi (yaomtc) - Sunday, 16 October 2016, 18:11 GMT
Lev: The controller works, I'm just talking about updating the firmware. Did you do that successfully from Arch?
Comment by Lev Lybin (lybin) - Sunday, 16 October 2016, 18:33 GMT
Yep, firmware update works successfully too. (Checked in only my build)
Comment by Yao Mitachi (yaomtc) - Sunday, 16 October 2016, 19:23 GMT
I installed your build just now, added myself to group steamcontroller, turned on the controller and started Steam. Still the firmware wouldn't update. After that I rebooted, then ran 'chmod 666 /dev/uinput' as root before starting Steam, but that didn't help either. There must be something different about my Arch install that's preventing this from working - either that or something's wrong with the controller itself. Probably the former.
Comment by Yao Mitachi (yaomtc) - Monday, 17 October 2016, 17:23 GMT
Found a guide to manually update firmware, so I worked around my issue.
Comment by Levente Polyak (anthraxx) - Friday, 09 December 2016, 02:09 GMT
Please test after rebooting.