All the Windows OS drivers for the Steam Deck OLED were released, except for the speakers for the device. But now, the driver is here so people can install Windows…if they want to!
On a more interesting topic, the SteamDeck platform drivers are still not merged into mainline Linux… :'(
Last news about it: https://www.phoronix.com/news/Steam-Deck-Platform-Driver-2024
Luckily their work is still done in the open and I can use the driver on my Deck on OpenSUSE despite it not being in the kernel.
Will they upstream those drivers to the kernel?
Well, for that look at @cmhe@lemmy.world’s link.
Writing working, finished code and changing that code to please the Linux kernel people are two very different things. I’m not surprised the Deck is still running a fork.
Well, it is about code quality. And the same codebase should work on different hardware, which is not something that is required in downstream forks.
But it is sad to see that the driver was submitted in the past, is still actively developed and improved, but there doesn’t seem to be plans of submitting them again.
Also I don’t think that a platform driver is so complicated that it requires such a long time for mainlineing. It not a filesystem or VPN.
Don’t underestimate the political/administrative hurdles for contributing code to projects like Linux. I doubt the technical challenges of the platform driver are keeping Valve from mainline.
Code quality can be a reason to get your code rejected, but often the problem is also getting the right people to look at things before the next conflicts, and formatting the code in the peculiar ways the Linux project likes to format their code. There are tons of patches containing perfectly correct and bug free code abandoned in the mail archives that’ll never get merged because attempts to upstream code were abandoned after back and forths with the team. There’s a wealth of code to be discovered in the mail archives that abandoned their efforts after being told to alter their mail client not to send HTML email alone.
To me, the abandoned effort to mainline code indicates a loss of interest, and that’s rarely caused by technical challenges.
On the upside, because the code is open source, anyone is free to submit the driver again and put in the work to adjust it to the requirements of the Linux kernel project. The Linux maintainers themselves can also step up and apply the necessary corrections, that I’m sure Valve would appreciate, to mainline the code.
Nothing of this is a burden, it is just part of being a good contributor that reads and follows the rules. Contributing is pretty easy, when you have read and are following the guides. If you haven’t already, you should give it a try.
I am pretty sure that this isn’t the first contribution of Valve to the Linux kernel. It sounds more to me like “works for me, don’t care about others” attitude. Which is not a good attitude to have when working in any collaborative project. (Not necessarily against the developers, could also be management.)
I understand that. But those rules are also making people give up on contributing to the kernel. When I put code out in the open for others to take advantage of as they wish, I don’t feel like adjusting my work to other people’s standards so that they can use my code.
Valve contributed to Linux before, so the fact that they don’t have any direct upstreaming plans right now indicates that something is causing friction.
Well, I consume more open source software that I will ever produce, so I am in a dept to the community. If it means working a bit more to make my contribution useful to others and fit it into the bigger whole, I will gladly do so.
Valve contributed to Linux before, so the fact that they don’t have any direct upstreaming plans right now indicates that something is causing friction.
I would avoid reading too much into it. They and their developers are still contributing on other stuff. Also when working together, there will always be some friction, in any public collaborative project ever.
