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.
Quoting: Shmerl"Done right" or not, it means removing user's choice.I prioritize "done right and just works" far above "complete freedom of users choice". Time is much to precious for me to spend hours into setting up my environment.
Edit: removed some ranting, it's not worth it.
Last edited by jens on 1 March 2018 at 9:01 pm UTC
0 Likes
slaapliedje Mar 2, 2018
To be fair, it does work on Linux wothout the client, but only in keyboard/mouse mode.
0 Likes
[quote=Shmerl]
Because that's how long it took before amdgpu came to be, or even longer... And amdgpu is about a fully established and fully defined API between applications and the hardware...
There still is no clear path for the steam controller.
You can follow a design path for years and finally reach a product and conclude it was a waste of time because it doesn't work as you have now realised, or you can play with the device, reiterate the way you want to use it, and only after that look at how the kernel should be modified to incorporate support for that.
As I said: look at what valve is doing for steamvr, they are modifying and patching and updating RADV and any other *open* (I think they are now looking at amdvlk too) drivers to what they think how VR should work, and push those patches upstream, even to Kronos to adjust the specs, and the linux kernel to fix how one should look at displays.
They are going full experimental on VR, but there is still 0 working product.
They can actually do that, because they get some idea how things should work using the windows platform.
The steamcontroller was working from day 1, but by keeping the full functionality in the steam client for now, they could keep on experimenting.
Ideas seems to be stable now, and Valve helps or hints in the development of the kernel drivers.
I still wonder how, because you still need a middle layer to convert the controller input to something the application groks. And I wonder how the the force feedback API will look like... Like an alsa PCM device (*that's* how much you control you can do)? Or like a rumble pad (dumb).
Quoting: ArdjeSee above, it's not an excuse not to upstream the driver. Proper example: amdgpu.So you expect us linux users to wait about 10 years before there is even a proper idea how to incorporate a product into the linux kernel?
Because that's how long it took before amdgpu came to be, or even longer... And amdgpu is about a fully established and fully defined API between applications and the hardware...
There still is no clear path for the steam controller.
You can follow a design path for years and finally reach a product and conclude it was a waste of time because it doesn't work as you have now realised, or you can play with the device, reiterate the way you want to use it, and only after that look at how the kernel should be modified to incorporate support for that.
As I said: look at what valve is doing for steamvr, they are modifying and patching and updating RADV and any other *open* (I think they are now looking at amdvlk too) drivers to what they think how VR should work, and push those patches upstream, even to Kronos to adjust the specs, and the linux kernel to fix how one should look at displays.
They are going full experimental on VR, but there is still 0 working product.
They can actually do that, because they get some idea how things should work using the windows platform.
The steamcontroller was working from day 1, but by keeping the full functionality in the steam client for now, they could keep on experimenting.
Ideas seems to be stable now, and Valve helps or hints in the development of the kernel drivers.
I still wonder how, because you still need a middle layer to convert the controller input to something the application groks. And I wonder how the the force feedback API will look like... Like an alsa PCM device (*that's* how much you control you can do)? Or like a rumble pad (dumb).
1 Likes, Who?
Quoting: GuestSo it's only black or white for you?Quoting: GuestQuoting: GuestBut I'm always told here that Valve is soooo supportive of Linux. Hmmm.I really don't understand what point you were making with your tone in your post.
Instead they keep HW details secret and have someone do reverse engineering to properly support Linux....
Did I say some thing bad?
No, your statement was/is absolutely correct.
My answer wasn't against you, but targeted at those people always claiming how supportive Valve is to Linux. Because the two statements don't really go together well....
0 Likes
Quoting: ArdjeSo you expect us linux users to wait about 10 years before there is even a proper idea how to incorporate a product into the linux kernel?
Because that's how long it took before amdgpu came to be, or even longer...
When the driver is a mess, let it take as long as it should to get upstreamed. amdgu is whole different level of complexity than the Steam controller though. So the later should not take as long.
And experimenting with drivers is not detrimental to keeping them open. So there is simply no excuse.
Last edited by Shmerl on 2 March 2018 at 2:08 pm UTC
0 Likes
Quoting: GuestGlad to read that, you initial posting on the subject suggests otherwise.Quoting: jensQuoting: GuestNo, your statement was/is absolutely correct.So it's only black or white for you?
My answer wasn't against you, but targeted at those people always claiming how supportive Valve is to Linux. Because the two statements don't really go together well....
On the contrary. I never denied Valve is contributing. I'm only pointing out that there are also black spots on their shirt that others seem to ignore/overlook.
0 Likes
slaapliedje Mar 2, 2018
I'd think (just a theory, I have no inside info) the reason they don't have kernel level drivers for the Steam Controller yet is because a lot of it is tied into the client, which is closed source. Also possibly tied into specifically big picture mode. I certainly know some aspects of the controller aren't accessible unless you are in BPM.
How does the kernel level driver plan on handling the configuration of the controller? I think these are all things Valve was considering before they just said 'screw it' and slapped it into Steam.
How does the kernel level driver plan on handling the configuration of the controller? I think these are all things Valve was considering before they just said 'screw it' and slapped it into Steam.
1 Likes, Who?
Quoting: jensBecause those two things are antithetical, and openness makes things work badly. Got it.Quoting: Shmerl"Done right" or not, it means removing user's choice.I prioritize "done right and just works" far above "complete freedom of users choice". Time is much to precious for me to spend hours into setting up my environment.
0 Likes
Quoting: Purple Library GuyFor this specific case here my assumption is that supporting the Steam Controller (for Steam games) the FOSS way would, as also stated by others, take considerably more time. The overall experience for Steam games i.c.w. the controller would be in the short time, my assumption, not as good as it is now. This does not exclude that the final result of both approaches can be of the same.Quoting: jensBecause those two things are antithetical, and openness makes things work badly. Got it.Quoting: Shmerl"Done right" or not, it means removing user's choice.I prioritize "done right and just works" far above "complete freedom of users choice". Time is much to precious for me to spend hours into setting up my environment.
-> "If you want to go fast, go alone. If you want to go far, go together." (African Proverb)
There are situation where going fast is a valid alternative, imho.
Just to be sure: FOSS and drivers upstream is cool and definitively the better way, just not the only way. There are different ways leading to Rome. I'm more pragmatic than others it seems, that's just all. Since Linux is supposed to be so much about freedom, why isn't Valve free to support their products te way they want? Valve is not forcing anybody to use their products. It works for them (and for me). People should simply choose different products and move on if they don't agree instead of cursing Valve continuously for their approach.
(English is not my native language, could be that I got your statement and the irony in it completely wrong. If my response makes no sense, then this is most likely the case.)
Last edited by jens on 3 March 2018 at 5:30 pm UTC
1 Likes, Who?
Quoting: jensJust to be sure: FOSS and drivers upstream is cool and definitively the better way, just not the only way. There are different ways leading to Rome. I'm more pragmatic than others it seems, that's just all. Since Linux is supposed to be so much about freedom, why isn't Valve free to support their products te way they want? Valve is not forcing anybody to use their products. It works for them (and for me). People should simply choose different products and move on if they don't agree instead of cursing Valve continuously for their approach.I do think good supported driver source eventually is the only way.
(English is not my native language, could be that I got your statement and the irony in it completely wrong. If my response makes no sense, then this is most likely the case.)
But I am pragmatic: sometimes a shortcut is easier so you know what to do for a real driver.
As the same pragmatic it usually is a good business choice to not buy hardware that has no (good) open source support. This pragmatic rule came after sinking a few thousand $ into the hardware vendor requesting them to port the driver.
Things are easy on ARM: you have opensource support, or we won't buy. Some things are not completely opensource but a large percentage of an exynos platform is opensource. At least much more than a PC.
1 Likes, Who?
Patreon
PayPal
See more from me