this post was submitted on 05 Sep 2024
1 points (100.0% liked)
Steam Deck
14797 readers
6 users here now
A place to discuss and support all things Steam Deck.
Replacement for r/steamdeck_linux.
As Lemmy doesn't have flairs yet, you can use these prefixes to indicate what type of post you have made, eg:
[Flair] My post title
The following is a list of suggested flairs:
[Discussion] - General discussion.
[Help] - A request for help or support.
[News] - News about the deck.
[PSA] - Sharing important information.
[Game] - News / info about a game on the deck.
[Update] - An update to a previous post.
[Meta] - Discussion about this community.
Some more Steam Deck specific flairs:
[Boot Screen] - Custom boot screens/videos.
[Selling] - If you are selling your deck.
These are not enforced, but they are encouraged.
Rules:
- Follow the rules of Sopuli
- Posts must be related to the Steam Deck in an obvious way.
- No piracy, there are other communities for that.
- Discussion of emulators are allowed, but no discussion on how to illegally acquire ROMs.
- This is a place of civil discussion, no trolling.
- Have fun.
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.