Work is under way to get proper Steam Controller support in the Linux Kernel

"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 Mar 2018 at 9:01 pm UTC

To be fair, it does work on Linux wothout the client, but only in keyboard/mouse mode.

[quote=Shmerl]

See 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).

But I'm always told here that Valve is soooo supportive of Linux. Hmmm.

Instead they keep HW details secret and have someone do reverse engineering to properly support Linux....

I really don't understand what point you were making with your tone in your post.
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....

So it's only black or white for you?

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...

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 Mar 2018 at 2:08 pm UTC

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....

So it's only black or white for you?

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.

Glad to read that, you initial posting on the subject suggests otherwise.

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.

"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.

Because those two things are antithetical, and openness makes things work badly. Got it.

"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.

Because those two things are antithetical, and openness makes things work badly. Got it.

For 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.

-> "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 Mar 2018 at 5:30 pm UTC

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.)

I do think good supported driver source eventually is the only way.
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.