Standalone Steam Controller driver and UI 'SC Controller' gets a sweet small upgrade

For the reference, there's a WIP Python 3 port at https://github.com/Ryochan7/sc-controller/tree/python3

It builds and runs fine, though I can't get it to recognize my SC properly, but I'm not sure it's related to the Python 3 port or a change in my distro (especially the Linux kernel's HID driver).

I've had really good experience with AppImage, its a great generic solution for stand-alone desktop apps.
It would be nice to manage them as apps that get updates, etc... but it's currently the lowest friction way to get a complex desktop app available for any Linux distro.

Oh wow, with the new Version finally its working. But it has way less options as the steamoverlay. Will be hard to setup a game with not all of these options I got so used to use one button for different actions and also using the action layers etc.


Last edited by Spirimint on 9 December 2020 at 12:35 pm UTC

I started building a snap for this as the AppImage just segfaulted back on Ubuntu 19.10. These days my snap seems to work (with a few rough edges) for the Steam Controller used via the dongle. I haven't tried Bluetooth or other controllers, yet, as I don't have the hardware; testers and bug-reporters welcome!

I'll have a look at making a release for the new version this evening.

One major issue is with most modern Linux distributions moving to a major Python update, which broke SC Controller. Thankfully, as of the v0.4.8 release that's not so much a problem with the AppImage now working on Ubuntu 20.04 and comparable distributions.

Python 3 has been out for 12 years, and Python 2 has been EOL for a year already. Containerisation is useful in its own right, but using it to limp along with a dead Python version doesn't seem like a great plan for something that's under active development.

I have had no issues with the Python 3 port, mentioned by Akien, on Arch. The AUR package switched over to that version in October.

Python 3 has been out for 12 years, and Python 2 has been EOL for a year already. Containerisation is useful in its own right, but using it to limp along with a dead Python version doesn't seem like a great plan for something that's under active development.

Well if it works, and it keeps useful applications alive, there's nothing wrong with it and there's people who have issues with the newer Python version of SC Controller. No need to have one solution forced on everyone, options are good for those who need it :)

Wait, wasn't this software development "halted" because the author was offended by "SJWs taking over" Linux community? He changed his mind or grew up?

I want SC2 from Valve :(

You're not the only one - the Steam Controller is the best controller I've ever used

Maybe the Valve Index controllers can be used outside of VR?

Nice to see it getting updates and a new release. The Fedora builds only go up to 30, and it doesn't have the required dependencies in 33 - looks like it still needs obsolete Python stuff?
Problem: conflicting requests
- nothing provides gnome-python2-rsvg needed by sc-controller-0.4.8-10.1.x86_64
- nothing provides pylibacl needed by sc-controller-0.4.8-10.1.x86_64

For the reference, there's a WIP Python 3 port

Will that possibly be upstreamed? Or is it more likely upstream will abandon Python altogether?

Great news! I love my Steam Controller so much. Even though I mainly use it in Steam, it's very nice to be able to use it for other games.
Does anyone know if it works with Stadia or GeForce NOW?

Does anyone know if it works with Stadia or GeForce NOW?

Yes, it works with both.

Very nice!

Nice to see it getting updates and a new release. The Fedora builds only go up to 30, and it doesn't have the required dependencies in 33 - looks like it still needs obsolete Python stuff?
Problem: conflicting requests
- nothing provides gnome-python2-rsvg needed by sc-controller-0.4.8-10.1.x86_64
- nothing provides pylibacl needed by sc-controller-0.4.8-10.1.x86_64

For the reference, there's a WIP Python 3 port

Will that possibly be upstreamed? Or is it more likely upstream will abandon Python altogether?

Easiest solution would be to use the Snap that /u/mcphail seems to have built or the AppImage. Both are cross-distro solutions either already working for you or easy to set up.

I've had really good experience with AppImage, its a great generic solution for stand-alone desktop apps.
It would be nice to manage them as apps that get updates, etc... but it's currently the lowest friction way to get a complex desktop app available for any Linux distro.

Lowest friction for developer - yes.
The extra effort of maintenance has been shifted from dev to user instead.

Does anyone know if it works with Stadia or GeForce NOW?

Yes, it works with both.

Thanks for the confirmation!

One major issue is with most modern Linux distributions moving to a major Python update, which broke SC Controller. Thankfully, as of the v0.4.8 release that's not so much a problem with the AppImage now working on Ubuntu 20.04 and comparable distributions.

Python 3 has been out for 12 years, and Python 2 has been EOL for a year already. Containerisation is useful in its own right, but using it to limp along with a dead Python version doesn't seem like a great plan for something that's under active development.

The problems created in the move from Python 2 to Python 3 seem to be one of the reasons Kozec is porting SCC over to C, and that's why he's not focused on creating a Python 3 port too. However, as Akien stated above, there is a functional Python 3 port of SCCavailable now thanks to the Community!

Does anyone know if it works with Stadia or GeForce NOW?

Liam would be able to say for sure regarding Stadia, but I'm going to say that it very probably does. SC-Controller (SCC) operates independently of game clients and games and can tell those games that whatever the Steam Controller input is, it's an input the game is expecting. Since SCC is available as an Appimage, it's nothing to download and tryout with Stadia, etc. Give it a try!



P.S. Full disclosure, I'm an SCC Patreon supporter from way back. If you like (or more likely love) Kozec's SC-Controller project and (like me) can't code or figure out Github, please consider financially contributing whatever you can.

You can support him at Liberapay, thru Patreon (like me), or directly via a donation at Paypal.


Last edited by Nanobang on 11 December 2020 at 4:23 pm UTC

Oh wow, with the new Version finally its working. But it has way less options as the steamoverlay. Will be hard to setup a game with not all of these options I got so used to use one button for different actions and also using the action layers etc.

tl;dr I'm an SC-Controller fanboy.

SCC may have fewer options than Steam's client, or it may not. I don't honestly know, but I think SCC may have more. A lot of what you see in Steam's UI is available in SCC, but you might have to do it differently. In many ways, Steam's UI is to Kozec's SC-Controller as Windows is to Linux: the first (Steam's) is simpler but is less customizable, fewer granular choices, and the second (Kozec's) is way more choices, but isn't as dumbed-down.

For example, the Activators in Steam's UI (Regular, hold, start press, etc.) are easily done in SCC, but are set-up in either mode-shift or macros. Action sets are done just by making another profile, otherwise it's the same, it's just that SCC doesn't keep track of that in the UI.

But SCC lets me do so many things Steam's client can't. In Steam an input can only have one mode shift. In SCC I can add as many mode-shifts to a button as I want: Press 'A' and pull the trigger, one thing happens; press 'B' and pull the same trigger, something else happens. Mode-shift combinations on the SCC are exponentially greater than Steam's UI. That alone would be enough for me to count SCC the better of the two.

Rings on pads are more configurable, so that more than just buttons can be placed in the rings. I'll give you an example based on my own basic Payday 2 SCC profile. Normally the Rpad is a trackball mouse to control a camera. On top of this I add a mode-shift so that when I click the RPad it becomes a DPad where LEFT is reload, UP is change weapon, DOWN is drop weapon, RIGHT is flashlight, and center is grenade. All that is doable in Steam's client, but with SCC I've added more. To more easily interact with Payday's menus, I added a mode shift so when I press the back button the very edge of the Rpad becomes a circular trackpad mouse-wheel and the center becomes an Arrow Dpad.

Once again, an open source solution outshines a proprietary one.


Last edited by Nanobang on 11 December 2020 at 5:13 pm UTC

Python 3 has been out for 12 years, and Python 2 has been EOL for a year already. Containerisation is useful in its own right, but using it to limp along with a dead Python version doesn't seem like a great plan for something that's under active development.

Well if it works, and it keeps useful applications alive, there's nothing wrong with it and there's people who have issues with the newer Python version of SC Controller. No need to have one solution forced on everyone, options are good for those who need it :)

In the current world though that's not a good idea. With vulnerabilities and malicious actors moving faster than most communities can keep up running out of date software is dangerous. It gets even worse if you live in a home where you and/or others are working from home, as a particularly bad vulnerability could give an attacker the ability to take over a PC and silently monitor the local network, potentially gaining access to a corporate network by getting VPN credentials with a MITM attack.

This is also why Windows Kernel-level Anti-Cheat is so dangerous as well.