Valve have changed the USB/Bluetooth communication the Steam Controller uses, so on Linux you will need to update your udev rules.
Note: This is for the Beta client, but works on the stable client too. Even if you're on the stable client, it's likely a good idea to do it now ready for the next stable release on the Steam client.
See their announcement here, which links to this guide of issues.
Funnily enough, Valve didn't even list the actual file you need to update, so here it is:
You can open it easily doing this in terminal (on Ubuntu for example):
Edit it to look like this (make sure you edit the group name like it says!):
I tried reloading udev rules after, but it didn't seem to work. A reboot with the new rules in place and it works once again.
Valve still haven't fixed the issue of the Steam Controller not working in wireless unless Steam is open though, bug reported here on September 1st. Not everyone seems to have that issue though.
Thanks to Furball in our Telegram group chat for pointing it out. Article taken from GamingOnLinux.com.
Note: This is for the Beta client, but works on the stable client too. Even if you're on the stable client, it's likely a good idea to do it now ready for the next stable release on the Steam client.
See their announcement here, which links to this guide of issues.
Funnily enough, Valve didn't even list the actual file you need to update, so here it is:
/lib/udev/rules.d/99-steam-controller-perms.rulesYou can open it easily doing this in terminal (on Ubuntu for example):
sudo gedit /lib/udev/rules.d/99-steam-controller-perms.rulesEdit it to look like this (make sure you edit the group name like it says!):
Quote# 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"
# DualShock 4 wired
SUBSYSTEM=="usb", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="05c4", MODE="0666"
# DualShock 4 wireless adapter
SUBSYSTEM=="usb", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="0ba0", MODE="0666"
# DualShock 4 slim wired
SUBSYSTEM=="usb", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="09cc", MODE="0666"
# Valve HID devices over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="28de", MODE="0666"
# Valve HID devices over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*28DE:*", MODE="0666"
# DualShock 4 over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*054C:05C4*", MODE="0666"
# DualShock 4 Slim over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*054C:09CC*", MODE="0666"
I tried reloading udev rules after, but it didn't seem to work. A reboot with the new rules in place and it works once again.
Valve still haven't fixed the issue of the Steam Controller not working in wireless unless Steam is open though, bug reported here on September 1st. Not everyone seems to have that issue though.
Thanks to Furball in our Telegram group chat for pointing it out. Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
The latest Steam installer available at:
already carries the changes to the udev files and also the renaming of 99-HTC-Vive-perms.rules to 60-HTC-Vive-perms.rules:
http://repo.steampowered.com/steam/pool/steam/s/steam/
steam_1.0.0.54.dsc 23-Nov-2016 18:46 1.2K
steam_1.0.0.54.tar.gz 23-Nov-2016 18:46 2.6M
steam_1.0.0.54_i386.deb 23-Nov-2016 18:46 4.8Kalready carries the changes to the udev files and also the renaming of 99-HTC-Vive-perms.rules to 60-HTC-Vive-perms.rules:
Quotesteam (1.0.0.54) precise; urgency=mediumDistributions just need to update their Steam package.
* Update controller udev rules to let Steam write to DualShock 4 HID nodes
-- Pierre-Loup A. Griffais <[email protected]> Sat, 29 Oct 2016 18:23:06 -0700
steam (1.0.0.53) precise; urgency=medium
* Update udev rules for HTC Vive and order them so they run after
50-udev-default.rules but before 73-seat-late.rules
-- John Vert <[email protected]> Wed, 18 May 2016 16:43:24 -0700
1 Likes, Who?
Quoting: GrifterI see a lot of bluetooth being mentioned, but I was under the impression that the steam controller used plain wifi instead of bluetooth, am I mistaken? Or is this new change changing over to bluetooth? Please enlighten my ignorance.
I suspect the bluetooth changes are for the Dual Shock 4 controllers
0 Likes
In the past it just works. Last tried a few days ago. I never ever set udev rules for the Steam Controller. Do I have to do this now?
EDIT: I use Xubuntu 16.4.
Last edited by 0aTT on 24 November 2016 at 12:36 pm UTC
EDIT: I use Xubuntu 16.4.
Last edited by 0aTT on 24 November 2016 at 12:36 pm UTC
0 Likes
Quoting: 0aTTIn the past it just works. Last tried a few days ago. I never ever set udev rules for the Steam Controller. Do I have to do this now?I use Ubuntu 16.04. The Steam controllers stop working yesterday. I did the udev change at my lunch break. But they are still not working. Will have to investigate further tonight :(
EDIT: I use Xubuntu 16.4.
0 Likes
Quoting: PerkeleenVittupEven MS themselves realize "something"; they joined the Linux Foundation as a platinum member. Linux will be de facto platform for gaming in future. Why not just speed the inevitable up?
MS does not care at all about Linux gaming and certainly did not join the Linux Foundation because of games. They're barely interested in Windows gaming...
They joined the foundation because of the the server market. They need perfect integration for their Azure platform for example.
0 Likes
I was hoping that somehow I would be able to magically apply the SteamOS hotpatch and all would be made well again.
Initially I just switched back to the stable branch client, but I can see this particular bork is not going to be fixed by the borkers. [waves fist futilely skywards, cursing the fates]
Addendum:
I had forgotten I used to use the Steam released steam client, but switched to Ubuntu's version when there was the "You're running an outdated version" message every time I started Steam. Is that bug still a problem, does anybody know?
Last edited by Nanobang on 24 November 2016 at 3:11 pm UTC
Initially I just switched back to the stable branch client, but I can see this particular bork is not going to be fixed by the borkers. [waves fist futilely skywards, cursing the fates]
Addendum:
Quoting: tgurrThe latest Steam installer available at:
http://repo.steampowered.com/steam/pool/steam/s/steam/
steam_1.0.0.54.dsc 23-Nov-2016 18:46 1.2K
steam_1.0.0.54.tar.gz 23-Nov-2016 18:46 2.6M
steam_1.0.0.54_i386.deb 23-Nov-2016 18:46 4.8K
already carries the changes to the udev files ...
I had forgotten I used to use the Steam released steam client, but switched to Ubuntu's version when there was the "You're running an outdated version" message every time I started Steam. Is that bug still a problem, does anybody know?
Last edited by Nanobang on 24 November 2016 at 3:11 pm UTC
0 Likes
slaapliedje Nov 24, 2016
Quoting: fcastilloWhat if I'm using Steam Link? I've notice a lot of disconnection problems on the Link, and recently there was an announcement for an update to SteamOS that fixes this. I'm not using SteamOS just the client on Ubuntu, but I'm seeing this problems because of the Link. Any suggestions?
I have that weird issue where if I connect to my Linux Desktop from the Link, that it then screws up the permissions so the Steam Controller stops working, so I have to go back to my computer and run a chmod 666 on it again.
Would be nice if this was finally fixed.
0 Likes
Heads up for those of you with a steam machine
Before upgrading the steam beta, forcefully upgrade your system.
If you don't, you need a mouse to get out of the mess, and the intended use-case for a steam machine does not include a mouse. The steam controller is *dead*/useless until steamos is updated (with the new udev rules).
Fortunately all steam machines are lacking CEC support in hardware, so my steam machine only lasted 1 hour on my TV, before migrating it back to my room and replacing it with a steam link.
(Why... Why say it is a console if you don't support CEC :-( ).
It's now connected to my KVM switch like a bunch of other stuff ;-).
Before upgrading the steam beta, forcefully upgrade your system.
If you don't, you need a mouse to get out of the mess, and the intended use-case for a steam machine does not include a mouse. The steam controller is *dead*/useless until steamos is updated (with the new udev rules).
Fortunately all steam machines are lacking CEC support in hardware, so my steam machine only lasted 1 hour on my TV, before migrating it back to my room and replacing it with a steam link.
(Why... Why say it is a console if you don't support CEC :-( ).
It's now connected to my KVM switch like a bunch of other stuff ;-).
0 Likes
I would recommend putting the rules in /etc/udev/rules.d instead.
udev, like a lot of other Linux software, store their configuration in several different places. Technically, you certainly can make that rules file in /lib rather than /etc and yes, it would work as it's expected to, but there's a logic and an order of precedence to each configuration location that should be conformed to, so as to avoid any potential behavioural issues in the future.
/lib/udev/rules.d = Location for default udev rules. This includes rules that came with udev itself, as well as rules that came with your distribution and other software installed through your package manager. If you create rules in this directory, they will work, but you risk them being clobbered (overwritten) by software and distribution upgrades, resulting in a "where the hell did my configuration go?!" scenario. Not good.
/usr/lib/udev/rules.d = Some distros use this instead of the above directory. In other distros it might even be a symlink to the directory above. In any case, same description as above.
/etc/udev/rules.d = Location for udev rules created by your local sysadmin. This is probably you. Anyway, you are the BOSS of this directory. Other packages shouldn't be installing rules in this directory, so if you haven't touched it before, it's probably empty. The point is, this is where you should be putting any rules you have to make for your system that aren't in /lib already. In the event that there's a rules file in multiple configuration locations with identical names (say, /lib/udev/rules.d/99-custom.rules and /etc/udev/rules.d/99-custom.rules, for example,) rules in this directory take precedence over rules in other locations.
When your distro includes the necessary changes to its Steam repo package's udev rules, it will likely put that file in the first or second location in /lib or /usr/lib. Keep a close eye on your updates for the next while, once it's integrated you can probably get away with deleting the file you created in /etc. This fix will eventually be automatically integrated into every distro's Steam repo packages, but for now this fix is very useful while we wait for our respective distros to catch up.
Hope this helps everyone out. Glad to finally be here, by the way. :)
Last edited by Ryblade on 25 November 2016 at 11:10 pm UTC
udev, like a lot of other Linux software, store their configuration in several different places. Technically, you certainly can make that rules file in /lib rather than /etc and yes, it would work as it's expected to, but there's a logic and an order of precedence to each configuration location that should be conformed to, so as to avoid any potential behavioural issues in the future.
/lib/udev/rules.d = Location for default udev rules. This includes rules that came with udev itself, as well as rules that came with your distribution and other software installed through your package manager. If you create rules in this directory, they will work, but you risk them being clobbered (overwritten) by software and distribution upgrades, resulting in a "where the hell did my configuration go?!" scenario. Not good.
/usr/lib/udev/rules.d = Some distros use this instead of the above directory. In other distros it might even be a symlink to the directory above. In any case, same description as above.
/etc/udev/rules.d = Location for udev rules created by your local sysadmin. This is probably you. Anyway, you are the BOSS of this directory. Other packages shouldn't be installing rules in this directory, so if you haven't touched it before, it's probably empty. The point is, this is where you should be putting any rules you have to make for your system that aren't in /lib already. In the event that there's a rules file in multiple configuration locations with identical names (say, /lib/udev/rules.d/99-custom.rules and /etc/udev/rules.d/99-custom.rules, for example,) rules in this directory take precedence over rules in other locations.
When your distro includes the necessary changes to its Steam repo package's udev rules, it will likely put that file in the first or second location in /lib or /usr/lib. Keep a close eye on your updates for the next while, once it's integrated you can probably get away with deleting the file you created in /etc. This fix will eventually be automatically integrated into every distro's Steam repo packages, but for now this fix is very useful while we wait for our respective distros to catch up.
Hope this helps everyone out. Glad to finally be here, by the way. :)
Last edited by Ryblade on 25 November 2016 at 11:10 pm UTC
2 Likes, Who?
Patreon
PayPal
See more from me