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.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
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:
steam (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?
I 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 Nov 2016 at 12:36 pm UTC
EDIT: I use Xubuntu 16.4.
Last edited by 0aTT on 24 Nov 2016 at 12:36 pm UTC
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?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
Even 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 Nov 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:
The 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 Nov 2016 at 3:11 pm UTC
0 Likes
slaapliedje 24 Nov 2016
What 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 Nov 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 Nov 2016 at 11:10 pm UTC
2 Likes, Who?
Pfff... You bunch of antarctic trolls. XD Fix the damn 6 in the gamepad emulation line before someone else goes crazy like me trying to understand what is wrong.
0 Likes
- MODE="0660"
+ MODE="0666"
+ MODE="0666"
0 Likes
slaapliedje 29 Dec 2016
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 ;-).
I was trying to figure out what drives CEC information. For example, the PS4 works fine with it, I don't think the Link actually does anything special with it, (though if I have the ps4 on, my receiver will switch to the link when it is powered on.) I should dig into this more, seems it should be a simple software thing.
1 Likes, Who?
I was trying to figure out what drives CEC information. For example, the PS4 works fine with it, I don't think the Link actually does anything special with it, (though if I have the ps4 on, my receiver will switch to the link when it is powered on.) I should dig into this more, seems it should be a simple software thing.The SoC in the link has full CEC support. It's up to the OS/application to do something with it. CEC has largely been ignored by the linux community until a few months ago when finally kernel infra support arrived for CEC.
But any generic PC with HDMI interface usually has nothing tied to the CEC line (so support impossible), and some even go so far to tie the CEC line to ground, which is an even bigger no-no. There has been one documented case of a toshiba notebook having a working CEC interface.
There are special cables that have the CEC line cut to connect generic bad PC's to a CEC setup.
CEC is like a bus where every device is electrically connected to the same wire. If one device short-circuits the line, the CEC bus is dead.
0 Likes
slaapliedje 8 Jan 2017
I love both of my steam controllers, they seem to be the ones that fit my hands the best, and so are extremely comfortable to me. Though I always wonder why the rumble is still marked as experimental.
0 Likes
I love both of my steam controllers, they seem to be the ones that fit my hands the best, and so are extremely comfortable to me. Though I always wonder why the rumble is still marked as experimental.I've used controllers before, and due to that I was very hesitant against controllers. I sometimes use my ps2 controller on android though, to play gta.
But the steam controller really is something different. It has both analog movement and mouse precision. As a matter of fact: although I have a roccat kone+ gaming mouse with a 30x30 roccat mouse pad, aiming using gyro on the steam controller is even better.
So yes, every game I use I try to start off using the steam controller.
I have 3 of them :-). Got the third with my steam machine as I needed my pc for something else, or turned off due to energy usage.
0 Likes
slaapliedje 9 Jan 2017
I really need to try the gyro out some more. I tried it a tiny bit in Fallout 4 when I had three screen set up, but it was.. odd. I kind of stopped playing Fallout 4 anyhow, since I hate booting into Windows.
I have a roccat Tyon, which is awesome. I noticed the whole 'gaming mouse pad' but... are they actually useful?
I have a roccat Tyon, which is awesome. I noticed the whole 'gaming mouse pad' but... are they actually useful?
0 Likes
I don't know if it is due this or something in Rocket League, but the analog stick and most of the buttons on my steam controller don't work in Rocket League anymore. I have the settings recommended here and rebooted but still nothing. I've just been playing with an old logitech controller. Running Fedora 24.
Last edited by m2mg2 on 19 Jan 2017 at 1:21 am UTC
Last edited by m2mg2 on 19 Jan 2017 at 1:21 am UTC
0 Likes
Patreon
PayPal
An idiots guide to setting up Minecraft on Steam Deck / SteamOS with controller support
How to install extra software, apps and games on SteamOS and Steam Deck
See more from me