Arch Linux

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.)

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.

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

I have started in on the after work beer a little to hard and early. I understand now you are completely correct. My apologies!

I am soon to be right behind you :P

I am going to be clearing out all my bugs tomorrow

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.

The problem is relevant for me.

Steam Controller known issues and platform-specific notes: https://steamcommunity.com/app/353370/discussions/0/490123197956024380/
```
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: http://repo.steampowered.com/steam/pool/steam/s/steam/steam_1.0.0.52.tar.gz
steam_1.0.0.52.tar.gz/utar://steam/lib/udev/rules.d

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.

Yes, I agree with you completely.

 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).

@medhefgo: please only post the very same text once. will be handled. thanks

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.

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

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:

https://bbs.archlinux.org/viewtopic.php?id=218318

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.)
https://www.reddit.com/r/SteamController/comments/57nh3s/support_new_steam_controller_firmware_update_not/

I use my build and still to works fine, can see inside PKGBUILD: https://dl.devtrue.net/archlinux/steam-client-1.0.0.52-4-x86_64.pkg.tar.xz

Lev: The controller works, I'm just talking about updating the firmware. Did you do that successfully from Arch?

Yep, firmware update works successfully too. (Checked in only my build)

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.

Found a guide to manually update firmware, so I worked around my issue.

Please test 1.0.0.54-1 after rebooting.