Slashdot Mirror
Should Linux Use Proprietary Drivers?
Richard Gray writes "Should Linux accept proprietary video/graphics drivers from likes of Nvidia and ATI ? The GPL written by FSF says that the license prohibits proprietary drivers. From the article: 'To write open-source graphics drivers without help from Nvidia or ATI is tough. Efforts to reverse-engineer open-source equivalents often are months behind and produce only 'rudimentary' drivers, said Michael Larabel, founder of a high-end Linux hardware site Phoronix ... Torvalds has argued that some proprietary modules should be permissible because they're not derived from the Linux kernel, but were originally designed to work with other operating systems.' The FSF however, sharply disagrees. 'If the kernel were pure GPL in its license terms...you couldn't link proprietary video drivers into it, whether dynamically or statically.' Where do you fall on this issue?"
You're missing the capitalistic incentive.
Nvidias and ATIs "value proposition" is the hardware. The driver is just a required evil.
Opening up the driver projects would mean they could get OSS loving hippies to do all the grunt MTRR/PAT/Register/MMIO/OpenGL hackery for them and they could concentrate on the actual hardware.
It's like AMD or Intel selling an OS. And saying "you must use this OS with this processor". That trick didn't fan out to well for IBM (System/360 anyone?) and wouldn't work for x86 processors either.
Why are GPUs any different?
Tom
Someday, I'll have a real sig.
How about the design of the graphics card, and the code that runs on the graphics card itself? Those aren't 'open' either. My optical mouse runs some code on it's little embedded CPU; that's not open source either. Or even the design of the AMD/Intel chip itself, and the microcode that runs on it?
In the real word, not all manufacturers of all components want to give you a "how to clone my life's work" guide, and you just have to live with that.
Worst BBC News Stories
I used to think having a Linux kernel driver ABI would be a good thing. But then I started to change once I read about the OpenBSD ilk and their trials with wireless, RAID, etc. (and their recent "blob" song). My attitude these days is "not in my kernel".
Binary blobs prevent peer review for security. They are in themselves a security risk as any vendor could use them to inject God-only-knows what hooks into the kernel (Sony rootkit native on Linux, anyone?). And I'd be more inclined trust the quality of code from the Linux community above and beyond anything proprietary.
I'd rather go without. If we must have binary drivers, they should either be run in user-space through a strict Free-software gateway or provided as a safe byte-code for a driver virtual machine.
The OpenBSD project has a very clear viewpoint on this issue. In fact, it's the theme for the upcoming 3.9 release song: http://www.openbsd.org/lyrics.html#39
Below are the reasons why the OpenBSD project is strongly opposed to using binary blobs:
I avoid the controversy.
/. seem to act as if NVIDIA and ATI were the only players. For most non gamers the Intel 3d chipset's and their open source drivers are sufficient. Not only that, they open source their wireless drivers too. I've been buying motherboards and laptops with builtin (i.e. much cheaper in the end) Intel chipsets for a while and their support has been a breath of fresh air. Plus their mother boards just seem to work. Stable, open and reliable.
Most people here on
I currently have a notebook with an ATI Mobility Radeon 9700. Frustrated by the lack of open source drivers, I installed the proprietary ones offered by ATI... Big mistake... it caused so many problems, one of which had been listed as a known bug for half a year by ATI.
If a vendor want's to close source their drivers, then that's their decision... However, they should provide a decent level of support. A known bug should not exist for any more than several months (imagine what people would say if they did this with their Windows drivers).
Linux users should not be treated as second class, if the vendors out there don't want to spend the time/resources developing good quality drivers, then why bother trying... instead, they should release as much documentation as possible about their products so others can.
I have a friend who owns an Nvidia graphics card and has had no problems with it. Secondly it seems that Nvidia's linux support surpasses ATI's. When it comes time for me to purchase a new PC, it will not contain an ATI graphics card.
Excuses Are Like Assholes - Everybody's Got One
I think the point NVidia is making is that the driver is a big part of the package they're selling. A buggy driver will make the entire package, including the hardware, look bad.
You obviously never used the early versions of NVidia's Linux (and later FreeBSD and Solaris) drivers. No one expects any software to be 100% bug free (yes, I know there are exceptions to that but on the whole this is true). And if you counter this; I offer up ATI's drivers, including their Windows drivers, as repost. I have yet to have an ATI product that did not suffer miserably from driver problems under any OS.
If writing a graphics driver is indeed very complex, the chance of FOSS developers including bugs is quite realistic. The simple fact that FOSS developers have not been able to produce good GPU drivers despite reverse-engineering demonstrates the level of complexity involved.
Do you know anything about reverse engineering? It is a hack no matter how you look at it. You are trying to guess what something does by observing it. How can this be compared to knowing what something does because you have the documentation right in front of you. Nice troll. Or not.
Such version would come at the expense of NVidia's reputation; if ATI keeps their drivers closed, ATI will have the more stable package in the typical consumers' eye.
How did you come to that conclusion?
Regardless so long as the drivers are proprietary, I will continue to load proprietary drivers into my kernel, the FSF has a fairly narrow minded view here, yes it would be great if the drivers were open, but they aren't, and I am not going to restrict my system capablities just because the FSF doesn't approve.
I pretty much felt the same way until nvidia dropped support for cards that are TNT2 and older. The older drivers from nvidia's download archive are tough to build against newer kernels.
Granted, a TNT2 with 32 megs isn't going to make Quake4 playable, but it will work for things like quake3 and the original Unreal Tournament just fine. Not to mention most of the free openGL stuff like tuxracer, chromium and openGL screen savers.
I understand that things like S3 texture compression are proprietary to Nvidia's partners and there could be problems there, but couldn't they open enough to get basic accelerated openGL working at least on their legacy products?
"If they have both, tell them we use Linux. And if they have that, tell them the computers are down." -Dave Chapelle
I won't be buying or recommending any more ATI products unless they show a marked improvement in the quality of their drivers. Both for Windows and Linux.
Open sourcing the drivers might make me consider going back to their products.
Firstly that is a very arrogant approach, some of the best developers in the world work on open source stuff, saying it is to hard is just stupid.
Or maybe it's just code for "We haven't got documentation for this stuff, and rely on the collective experience of our developers over generations of the product to keep writing drivers. Driver writing is not a revenue center but a cost center for us, and in order to contain costs, we're not going to make the upfront investment required to throw our developers at documenting this stuff to the point where we won't be embarassed."
Intellectual property issues like cross-patent licensing and 3rd party code could be addressed relatively cheaply when compared to addressing systematic deficiencies in documentation and code style. Such an effort would turn the cost structure of a hardware company on its head.
Yes, they would ultimately experience an advantage from having unpaid volunteers improving their code. However, in order for those volunteers to improve the stuff, the stuff's already got to be in good shape anyway.
Even though I'd already done most of the reverse engineering, the extra notes in the spec allowed me to improve my program greatly -- and with much assurance.
Graphics chips, on the other hand, are far more complex creatures, so it's going to be even easier to figure out that if you turn on this bit here after you turn off that bit over there, you enable the high-speed texturing using that, otherwise seemingly useless block of memory.
Once you have the docs, it's easy. Until then, you can spend months trying to figure out how to enable that new capability, and a day or two implementing what you just figured out.
On the other hand, chip manufacturers can gain from releasing their code to the public because the OS community can often take over the job of supporting the device, and sometimes figure out how to do things that would shock the original designers.
If nothing else, just release the specs, and see what the open source geeks can do. It may seem like there's no ability, but all it really takes is an army of mediocre geeks to do the bulk of the coding and one or two uber-geeks to tweak that last 5-10% that makes the difference between an ok driver and a really good one.
That's how Open Source works.
Free Software: Like love, it grows best when given away.