We're talking about having a constant up-to-date driver on par with Windows for a major GPU card manufacturer. A driver which has caused a large amount of desktop users to return to Windows due to its historical issues.
While I get the reasoning for rejection, the typical OSS rejection attitude is also problematic. I kinda don't see a dialog happening here on how to resolve problems both sides have, just a repeat of posturing which has historically brought us awesome things like binary blob drivers that only work with single version of kernels (yes, I'm looking at you every ARM GPU ever!).
Nvidia manages to do this without any conflict with the kernel maintainers by simply not mainlining the code. If functionality trumps code quality, AMD can release kernel modules.
Perhaps the best current solution for all parties is for AMD publish sources on github and release kernel modules while getting PRs from the community to get the code up to meet the kernel standards. When the time comes, it will be duly mainlined.
https://www.youtube.com/watch?v=iYWzMvlj2RQ
> Nvidia has been the single worst company we've ever dealt with.
> - Linus
Kernel devs are antagonizing the only two GPU makers that matters. Besides the kernel, there has been some flame going between NVIDIA and Wayland devs too. Open source devs are immature men who do not understand the word compromise.
> Nvidia has been the single worst company we've ever dealt with.
> - Linus
This had nothing to do with the kernel and everything to do with the lack of optimus support (years later, its still shit).
> Kernel devs are antagonizing the only two GPU makers that matters
Maybe the 2 should ask Intel for some pointers on how to contribute to the kernel the right way.
> Open source devs are immature men who do not understand the word compromise.
I suspect that's part of the reason the kernel is stable, and for that I'm thankful. Not compromising on code quality is something I wish more projects would do, if they had the well-earned political/social capital the Linux kernel has.
Intel is not waiting for them to ask:
https://lists.freedesktop.org/archives/dri-devel/2016-Decemb...
> This is something you need to fix, or it'll stay completely painful forever. It's hard work and takes years, but here at Intel we pulled it off. We can upstream everything from a _very_ early stage (can't tell you how early). And we have full marketing approval for that. If you watch the i915 commit stream you can see how our code is chasing updates from the hw engineers debugging things.
(More specific advice follows.)
If AMD manages to reach that level of out-of-the-box working graphics driver, that will definitely reflect positively on their brand of graphics cards, and might give them an advantage over Nvidia.
I suspect that working with the kernel developers and maintainers will also be beneficial to the driver itself. It seems to me that for cooperating you gain valuable feedback on your code from people well-versed in kernel and driver code.
I extend my sympathy to anyone paid to contribute code to Linux.
Most people who are paid to contribute to Linux, including myself, are very happy to do so, and no, it's not a case of Stockholm syndrome.
I keep seeing already cash strapped projects go off the rails because someone decides that they need a gender oriented outreach program, complete with elaborate gatherings and whatsnot.
And when that crash and burns, their excuse for the cash bonfire is that the FOSS world is misogynistic...
In late October they dropped a steaming pile of 100k lines of code with a HAL and are whining it isn't getting merged.
The solution is AMD keeps code out of mainline or obeys kernel code standards.
Now we're up to 100K+
https://lists.freedesktop.org/archives/dri-devel/2016-Februa...
Who's to say its replacement will be any better? If the hygiene isn't there, maybe the quality isn't either.
Kernel developers do not care. They care about good software.
Define "good." Is quality a thing just defined by code style and properness, or is it defined as fitness for a purpose, connection to human use and usefulness, usability or function, or lack of defects to the end user?
Define "software." Is software just code, or does it also include the experience the code generates for the user? Is software only considered in terms of what developers of software are interested in, or does it include what users need and want?
Of course Linux kernel developers are only interested in narrow definitions of those things, and that's surely part of the problem. It's good to think about what "good software" really means, in my opinion.
Additional shit in mainline increases the maintenance burden. If the code isn't putting upstream maintainability above all else in its implementation, then it's generally not getting merged unless someone wasn't paying attention or some other forces compelled an exception.
Alex's first reply reads like he's willfully ignoring that aspect of the NACK. It's not a coding style issue, it's a HAL issue. Upstream isn't interested in maintaining a HAL and living with the impedance mismatch from day zero. The driver can stay out of tree. This is just about code getting into mainline.
I'm personally very happy to see the gpu subsystem maintainers paying attention and having the maturity to know a fool's errand when they see it.