I wouldn't necessarily blame the "WLAN, sound, or sleep" thing on linux. I'd blame that on cheap parts manufacturers that refuse to distribute open source drivers for fear of releasing company secrets and lack of profit margins to operate on.
I don't understand why would anyone not open-source their drivers?
What's NVIDIA's secret sauce? Being able to build great silicon.
What's Intel's secret sauce? Being able to build great silicon.
What's Samsung's secret sauce? Being able to put together great silicon.
So let's say tomorrow Nvidia open-sources all their drivers?
So now you know that which registers do you use to shade what. So now what's AMD going to do? Copy the interface?
It's already copied. Most users use standard OpenGL/DirectX to communicate with their board.
I mean look at Intel. You practically know what's what there. You can make an OS on (at least older) Intel chips without drivers.
Did it help anyone compete?
OK, so the question is upstream. Why would Qualcomm, ARM, or any upstream care about people finding out the interface to their hardware?
What secrets are there in the drivers?
As I understand things (which I'm clearly not an expert at all), CPU opcode is like an ABI,
put this value into register A, this value into register B, and a magic opcode into register C,
and poof, the register D contains the value of A+B.
A driver will say that you put int X into memory point A, Y into memory point A+1, and call function C with argument of A and D will contain the multiplied number.
So how does #2 protect IP over #1?
Let's also say your hardware implements g, h and i, but doesn't wire them together yet. So, your driver's code calls the three functions.
Unknown to you, the trick to use that decomposition is patented. if you release your driver's source code, you make it easier for the patent holder to figure out that you are violating their patent (your programmers might even have made it patently obvious by mentioning the paper describing the trick in a comment)
Unlikely? Maybe, but the way patents are written, who knows? For an almost random example, I searched for "driver code and hardware patents". The first link I clicked was https://www.google.ch/patents/US20090006831. Reading that, I wouldn't know what driver would _not_ infringe on it.
Also, there are many patents on ways to move data around efficiently. Avoiding all of them while still writing a performant driver at not be possible.
On the other hand it also seems reasonable that a compiler for e.g. NVIDIA's hardware might be hard to re-target to another vendor's hardware while retaining the same advantage.
NVidia's defining characteristic has been designing good drivers.
Even when they've been behind ATI/AMD in hardware, they've been ahead in driver stability and performance. Especially on Linux where they largely own the CG/post/design market (which mostly uses Linux workstations) and they are the only GPU vendor that has somehow squeezed Windows-competitive performance out of Xorg.
This. When shopping for discrete video cards, I no longer look at AMD's offerings because I'm not willing to fight with their driver, fret over whether or not I should apply updates, etc.
First, read this: http://www.gamedev.net/topic/666419-what-are-your-opinions-o...
So basically, most 3D applications and games are broken to a certain degree. Both NVIDIA and AMD invested quite a lot resources into making those applications run at acceptable level and not looking broken.
Now, when you figure out how to unbroke something and put it into fast path, your competitor can lift that easily into their driver. Neither of these players want that.
The good news is, that DX12/Vulkan/Metal have quite a different approach, they don't have complicated state machine and validation in the driver, making the driver simpler and these workarounds unnecessary. If everything goes well, we may see drivers for these stacks.
Microsoft has a lot of resources to incentivize hardware manufacturers to go to great lengths to make sure their drivers work well with Windows. No organization connected with "Desktop Linux" has that.
the reason Linux drivers are a "mess" is that the hardware they are trying to support are a mess, and said mess is papered over in Windows by the OEM drivers.