In addition to an update to the excellent SC Controller software, it seems there's also work towards getting full Steam Controller support in the Linux Kernel.
Currently, to get proper use out of the Steam Controller you either need the Steam client open, or to use something like SC Controller. However, this could change due to the reverse engineering effort from one hacker. This is actually the second revision to their patches, which cleans it up and implements a few more features.
Part of the problem, is that currently it will show up as multiple different types of devices like a virtual keyboard, a virtual mouse and so on. Here's what the developer of the patch said:
This driver was reverse engineered to provide direct kernel support in case you cannot, or do not want to, use Valve Steam Client. It disables the virtual keyboard and mouse, as they are not so useful when you have a working gamepad.
Working: buttons, axes, pads, wireless connect/disconnect.
TO-DO: Battery, force-feedback, accelerometer/gyro, led, beeper...
They said they are working on a third revision to the patches and there will likely be more work to be done if it is to be accepted. Valve developer Pierre-Loup A. Griffais has been commenting on the mailing list as well to provide some help and ask questions. Part of the issue, is this needs to not break support for the Steam Controller with the Steam Client or other software like SC Controller. Nothing seems set in stone right now in regards to this particular code, so it will be interesting to see what happens.
You can find the information here on the mailing list.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
slaapliedje Feb 28, 2018
I think the biggest benefit of this will be things like the RetroPie, where there is no steam client, and the sc-xbox.py does something funky with the triggers (probably due to them having analog/button ranges.)
0 Likes
Quoting: MalQuoting: ShmerlWhy can't Valve make such driver and use it directly after that?
First thing I can think of because otherwise they would then depend from linux kernel release process for steam controller updates and features. And linux kernel guys have comprehensively other priorities. So it makes sense for them to leverage steam client to deliver their software since it's already good at doing that.
That's not a proper Linux approach, and Valve should know that. AMD for example could argue the same thing (like Nvidia did). But they decided to be a good Linux citizen. So can Valve.
Last edited by Shmerl on 28 February 2018 at 7:53 pm UTC
1 Likes, Who?
Quoting: ShmerlQuoting: MalQuoting: ShmerlWhy can't Valve make such driver and use it directly after that?
First thing I can think of because otherwise they would then depend from linux kernel release process for steam controller updates and features. And linux kernel guys have comprehensively other priorities. So it makes sense for them to leverage steam client to deliver their software since it's already good at doing that.
That's not a proper Linux approach, and Valve should know that. AMD for example could argue the same thing (like Nvidia did). But they decided to be a good Linux citizen. So can Valve.
That is not a proper FOSS approach, correct. Fortunately Linux is more than FOSS. It works for them and for lots of other people on Linux. Pragmatism is sometimes needed to get things done.
Last edited by jens on 28 February 2018 at 8:34 pm UTC
1 Likes, Who?
Quoting: jensThat is not a proper FOSS approach, correct. Fortunately Linux is more than FOSS.
While it's not a FOSS approach in general indeed, it's not a Linux approach in particular either. Drivers that are not upstreamed that is. Linux kernel maintainers are very clear on this point.
Not upstreaming has nothing to do with pragmatism. The driver can be upstreamed and shipped as kernel module for easier external installation of experimental updates that weren't upstreamed yet. AMD are doing exactly that.
Last edited by Shmerl on 1 March 2018 at 2:10 am UTC
3 Likes, Who?
slaapliedje Mar 1, 2018
Not to mention that drivers in the mainline kernel tend to not gather dust, like ones you have to compile outside. Like I'm pretty sure this weird parallel port web cam I used to have no longer will compile with a newer kernel, so won't work. Granted webcams are so cheap now...
0 Likes
Quoting: ShmerlQuoting: jensThat is not a proper FOSS approach, correct. Fortunately Linux is more than FOSS.
While it's not a FOSS approach in general indeed, it's not a Linux approach in particular either. Drivers that are not upstreamed that is. Linux kernel maintainers are very clear on this point.
Not upstreaming has nothing to do with pragmatism. The driver can be upstreamed and shipped as kernel module for easier external installation of experimental updates that weren't upstreamed yet. AMD are doing exactly that.
Ok, I'll admit I reacted a little bit strong, I guess because this thread tented again to go into bashing Valve because they are not doing it "our" way.
Certainly it would be much better if the controller was supported on kernel level. Though it works for them (and for me), thus I'm fine with it. I can understand that things look different when one sees only the devil in Steam.
Regarding tying hardware to software, I don't see a problem to that approach either. When done right (especially the software part), the overall experience can be much better. Yes, I usually like Apple products ;)
1 Likes, Who?
Quoting: jensRegarding tying hardware to software, I don't see a problem to that approach either. When done right (especially the software part), the overall experience can be much better. Yes, I usually like Apple products ;)
The problem is obvious, forcing users to use specific software tied to some store, to access that hardware. That's especially a major problem when that software isn't FOSS. "Done right" or not, it means removing user's choice.
Last edited by Shmerl on 1 March 2018 at 6:08 am UTC
0 Likes
Quoting: ShmerlWhy can't Valve make such driver and use it directly after that?Because Valve is not expecting you to run the latest and greatest bazinga kernel on your old debian install.
What they did fits perfectly into the confined spaces of a stable desktop environment.
Everything else they do is alpha an requires you to run bleeding edge, as such they also do not advertise it as ready.
You need bleeding edge for full VR support for instance. They are constantly hacking and updating mesa/radv/anything.
But the steamcontroller is a stable product, intended for linux desktops running a stable distribution.
That's how simple it is.
EDIT:
And another thing:
When the steamcontroller became available, Valve had done some serious reworks on how to use it. Even this day I doubt it would be a good idea to set the use of this controller in stone (i.e.: the kernel). It's still not clear what is the best approach to use it. What is clear however is that Valve's tactic to rebind and make menus and other things for generic emulation of other controllers is at least 1 good approach. Binding the controller I/O dataformat also means no more firmware updates to support yet another great idea.
And great ideas to enjoy gaming even further is I think the reason Valve exists.
Last edited by Ardje on 1 March 2018 at 9:04 am UTC
0 Likes
Quoting: ShmerlQuoting: MalQuoting: ShmerlWhy can't Valve make such driver and use it directly after that?
First thing I can think of because otherwise they would then depend from linux kernel release process for steam controller updates and features. And linux kernel guys have comprehensively other priorities. So it makes sense for them to leverage steam client to deliver their software since it's already good at doing that.
That's not a proper Linux approach, and Valve should know that. AMD for example could argue the same thing (like Nvidia did). But they decided to be a good Linux citizen. So can Valve.
Ok I get it. But the Steam Controller Linux driver is not just a "kernel module". There is the kernel side and there is the firmware on the controller. Both of which requires to be upgraded in synch, automagically (given that the target audience are masses not just techies) and given the experimental nature of the hardware to support in parallel an easy switchable stable branch and beta program with frequent updates and roll backs as well. And there are also all the controller profile features that can only exist if they have an on line account and a cloud to leverage so Valve was already bound to use their client to deliver these anyway. In their cloths I would have done the same and kept the things simple.
Now Steam Controller -as opposed to the whole Steam Machine thing- was a huge success. A large part of this success has been possible because they took this way in the first place and were allowed to evolve it very fast. And ok: the device is not experimental anymore. The updates are pushed less frequently and maybe the time could be right to transition into a more conventional linux approach and maybe use the steam client only for the firmware updates. Yet doing that would cost resources and bring very limited benefit to the average user compared to now so it's hard to justify the investment cost. Supporting foss volunteers now that they emerged seems a good compromise to me.
Last edited by Mal on 1 March 2018 at 10:37 am UTC
3 Likes, Who?
Quoting: ArdjeBecause Valve is not expecting you to run the latest and greatest bazinga kernel on your old debian install.
What they did fits perfectly into the confined spaces of a stable desktop environment.
See above, it's not an excuse not to upstream the driver. Proper example: amdgpu.
And regarding the firmware, it should have been open source to begin with, Valve even promised that much. But they never opened it.
Last edited by Shmerl on 1 March 2018 at 3:32 pm UTC
0 Likes
Patreon
PayPal
See more from me