Slashdot Log In
Should Linux Use Proprietary Drivers?
Posted by
Zonk
on Tue Apr 18, 2006 08:11 AM
from the bring-the-shiny-to-the-penguin dept.
from the bring-the-shiny-to-the-penguin dept.
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?"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Come on (Score:5, Insightful)
As for this statement:
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. As for customers not asking for open-source drivers, all I can say is huh? There have been dozens of calls over the years for drivers to be open sourced!
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.
Re:Come on (Score:5, Insightful)
And they ship millions of units per year. So while every few years a few thousand people may clamor for them to change thier business models and practices (which is expensive to thier eyes), millions more happily use thier products without a problem.
What do you think thier course of action would be here? They could lose every Linux customer they have, and it would probably not adversely affect thier bottom line too much.
Parent
Re:Come on (Score:4, Insightful)
Futhermore, nvidia could choose to release docs for their cards which are no longer "state of the art" which would allow the community to take over maintainance and not give away "secrets" to their competitors (once the cards are out for 6 months or so, there are no "secrets" anymore that would harm their ability to compete.)
To continue to withhold docs for older cards / hardware is POINTLESS and hurtful.
Parent
Re:Come on (Score:4, Insightful)
Also, in many cases there is technology or code that is licensed and *can't* be released as open source because the people that own it don't want it released.
Finally, even if the developers want to do open source, their management may not (yet) be on board with open source.
Given time and good experiences, I think most hardware vendors will provide open source drivers. We just need to encourage them to do this rather than beating them over the head with it!
Parent
Re:Come on (Score:3)
Precisely my - driver developer's - point.
All the "Open Source Drivers" campaign is in fact has only one big stimulus: shitty proprietary drivers. In fact *very* *very* *very* shitty proprietary drivers. (Even M$ started developing drivers for supported hardware - quality is just outrageous).
When you have open source driver - you can fix it in matter of hours. I did that several times. With shitty drivers, normally comes shitty support.
Re:Come on (Score:5, Insightful)
There IS a cost for companies to release closed source code to the open source world, it's significant, and in terms of support it can be ongoing (and if they put thier foot down and refuse to support modified code then they look bad to thier customers who don't know any better).
Parent
Re:Come on (Score:4, Insightful)
GPUs are predominately massive FPGAs with a highly specialized IO ring (at least they were when I was in the field). The driver essentially loads the array when the card boots. Opening that portion of the driver opend your design to the competitor. Similar things in some chipsets.
I personally would be happy with a well supported binary driver over a half assed open one.
-nB
Parent
Re:Come on (Score:3, Informative)
A GPU is an ASIC for obvious reasons. (Cost and performance being the major contendors I suppose.) While you may be able to do some minor adjustments as well as turning on or off different shader pipelines it has nowhere near the flexibility of a FPGA.
General Purpose GPUs has nothing to do w
Re:Come on (Score:5, Insightful)
A huge chunk of it is drivers. Frequently you will see new driver releases that massively improve performance in certain games without diminishing visual quality. That's all "proprietary" software R&D that no sane company is going to publish for their competitiors. And then you have "professional" cards where literally the only difference is drivers certification.
Anyway, there's a giant difference in video drivers and (say) ethernet drivers in terms of the importance of driver R&D.
Parent
Re:Come on (Score:3, Insightful)
It's hard in the sense that the specifications of the underlying hardware are not available, and have to be inferred from its observed behavior to "reverse engineer" the driver.
I am not going to restrict my system capablities just because the FSF doesn't approve.
That's not the point here. FSF doesn't care whose drivers you use, or whether everything on your sys
Older nvidia cards... (Score:3, Interesting)
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 T
Re:Come on (Score:4, Interesting)
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.
Parent
Re:Come on (Score:5, Insightful)
Previously, they used other arguments: [ffii.org]
Parent
Re:Come on (Score:5, Interesting)
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?
Parent
Re:Come on (Score:4, Interesting)
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.
Parent
Re:Come on (Score:3, Insightful)
There have been several times that things have worked with OSS drivers that dont work with the proprietary ones. For example, try running NVidias proprietary drivers on a system with a Xen kernel. If you manage to get them to build and load at all, after hitting the big powerbutton on your now dead machine, try running the opensource drivers.
Proprietary drivers are often much worse than their OSS equivalents, and graphics driver
Re:Come on (Score:3, Interesting)
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
Re:Come on (Score:3, Informative)
There's source code for a kernel hook for the binary driver. The actual core of the driver is neither Open Source or Free Software.
Why not? (Score:5, Insightful)
The real question is: Should we buy hardware with closed source drivers.
Tom
Re:Why not? (Score:3, Insightful)
But binary blobs, and their open source equivalents (drivers written under NDA), are common in Linux. While OpenBSD is free and fights for hardware docs, the Linux crowd just sits on the sideline doing nothing.
Sometimes (Score:3, Insightful)
Re:Sometimes (Score:3, Insightful)
That's not to say the opensource driver people can't develop a great driver given the necessary documentation, just that sometimes proprietary drivers aren't all bad. And as someone else mentione
Re:Sometimes (Score:5, Insightful)
There you have it. If Linux systems ever want to develop greater market penetration and actually challenge the dominance of Windows, they need to to be able to handle all the same things, including video. I say, use the proprietary drivers until approrpiate ones can be reverse engineered, then dump them for the open source versions. If more and more people begin to use Linux systems, eventually the graphics systems manufacturers are going to have to cave to market forces and support the open source system.
Parent
Re:Sometimes (Score:5, Insightful)
RMS eventually founded the FSF because he couldn't get the source code to a broken printer driver. Learn your history or be doomed to repeat it.
Parent
Well .. (Score:3, Insightful)
Well.. has he get the driver code yet ?
Re:Sometimes (Score:3, Funny)
Don't even joke like that. I don't think I could handle TWO Stallmans.
RMS/FSF failed, still no driver (Score:3, Insightful)
RMS eventually founded the FSF because he couldn't get the source code to a broken printer driver. Learn your history or be doomed to repeat it.
History doesn't change facts, it helps explain them. In this case the fact is RMS is still *not* getting the driver, I guess that makes the FSF a failure.
In any case, useability is still the champ.
Wrong way around (Score:3, Insightful)
Proprietary drivers should never have been allowed to link to the linux kernel - doing so makes them a derivitive (yes, even those drivers that predate the linux kernel). Allowing them to link has diluted efforts to create free drivers, diluted the GPL's effectiveness (in the kernel) and allowed Nvidia & ATI to appear to be contributing more then they actually are.
I'm lucky (hah!) enogh to be using a driver from a vendor [sourceforge.net] who shows a little more support for OSS, but while the software is quite stable, the actual hardware is crap (and utterly useless for games).
Re:Wrong way around (Score:4, Interesting)
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
Parent
Re:Wrong way around (Score:5, Insightful)
Yeah, nobody, not AMD, not Intel, NOBODY would want to repeat the s/360 debacle. Domintaing an industry for decades, tens of billions in sales. Really. Who wants that?
Parent
Download them (Score:3, Insightful)
As others have pointed out... (Score:5, Insightful)
Any move by the FSF to prohibit this will only drive people away from Linux, since it's not likely that NVidia and ATI will ever open their drivers completely. Free Software is great for some things, but occasionally the FSF has to recognize that some proprietary elements are unavoidable.
Open (Score:5, Insightful)
Oh goody (Score:3, Insightful)
The kernel should offer API's, no more and no less (Score:5, Insightful)
Re:The kernel should offer API's, no more and no l (Score:3, Insightful)
The standard Linux kernel API (syscalls, etc.) presumably isn't sufficient to write a high-performance video driver. That's why they're writing kernel modules instead of applications. But kernel modules by their nature are loaded into the same memory space as the
Open Graphics Project (Score:5, Informative)
Re:Open Graphics Project (Score:4, Insightful)
I hate IP issues as much as the next slashdotter but I really can't see this taking off.
LinuxBIOS has taken off in a TINY way because it allows large Linux-dependent companies to boot their machines faster for a tiny piece of free code that they can stick on a £5 flash chip themselves with a £100 device.
OpenCores and the like haven't because the designs are fantastic but to actually put them into hardware in any bulk way costs an awful lot of money.
OGP is basically a large OpenCore project that relies on being able to manufacture cards that are built with some VERY expensive components, for a final price which may be way more than any average graphics card on the market but yet can't outperform that average card. And there's no way to reduce that cost even if you were to assemble it yourself (in fact, it would probably cost more).
And then you have, say, 10,000 units of these cards that you sell at just over cost (literally, because any more and people would laugh at the price tag). The profit you would make would be nowhere near enough to justify the effort, to secure the next batch or to convince some investor to plant millions into the scheme.
And in the end you get a few thousand people who are happy running an open system that costs them much, much more in terms of time, effort and money than **any** card on the market.
It's not going to change the world and it's REALLY NOT going to be available anytime soon in any shop (even the ones who stock every obscure component known to man etc.) for anyone to even notice it exists. By the time it gets there, it's going to be obsolete. By the time the new, improved model is released, it will also be obsolete.
Then you have legal problems like what if nVidia decides it hold a patent on something (hardware patents are much easier to enforce than software)? What if the cards explode in someone's machine? The disclaimers are all well and good but the slightest bad press will kill the entire project stone dead.
And in the end a graphics card is just a graphics card. Those that need the fancy 3D are gamers (who don't care about binaries) or 3D professionals (who wouldn't touch stuff like OGP with no warranties, no performance advantage, etc.).
Parent
Or buy VIA (Score:5, Informative)
It's also a nice stable silent mini board with a CPU that runs on 4W of power.
If you don't need gaming-level 3D performance or heavy number crunching power, a VIA EPIA-based system is a great option.
(And no, I have no financial ties to VIA.)
Parent
Not in my kernel (Score:5, Interesting)
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.
Who cares? The kernel license has an exemption. (Score:3, Insightful)
Snappy Answers to Stupid Questions (Score:5, Insightful)
A: No.
A little more seriously, let me just repost part of a comment that really illustrates the veracity of this answer:
(seen on slashdot, not said by me)
Yes. (Score:3, Funny)
GPL over the users (Score:5, Insightful)
Re:GPL over the users (Score:3, Insightful)
If we gain (the use of functionality
No proprietary drivers (Score:3, Insightful)
There are many advantages to Open Source software, and to me, being fully in control of your computer is one of them. But when I used the NVidia driver I was not in control. When it was first announced I was in the process of building a new PC. On the basis of NVidia officially supporting FreeBSD, I decided on a GeForce card to show my reciprocal support. For a few months I was happy. Then the proprietary nature of the driver rose up and bit me. When a new FreeBSD CD set arrived on my doorstep via my subscription, I wasn't able to use it until NVidia updated their driver.
The last straw came when after SIX MONTHS of no updates, I went searching around for reasons. It turned out that NVidia had decided not to update the driver because they were tired of tracking an evolving kernel. They weren't going to release a new Binary Blob(tm) until the 5.x branch was declared stable. While that might make sense on the surface, how come none of the Open Source XFree86/X.org drivers had the same issue? How come none of the Open Source DRI drivers in FreeBSD had the same issue? This was especially painful because the driver KEPT CRASHING the kernel! In twenty five years of using Unix, BSD and Linux, this has been the only time I have seen a kernel crash.
I went to the store and bought a low end Radeon. I am using the Open Source radeon driver, and couldn't be happier. It has never crashed on me, and I never have to wait for someone to get around to syncing it up with an OS upgrade. The transition from FreeBSD 5.x to 6.0 was painless, which is how it should be.
Keep the Binary Blobs(tm) out of my operating system!
Re:Well, since it's a proprietary card... (Score:4, Insightful)
Not true. I want OEMs to write the drivers because they have the specs in front of them. Networking drivers have shown many times that releasing the spec to OS programmers often results in better drivers than the OEMs. There's no reason to assume the same can't happen with video drivers.
TWW
Parent
Re:If you're going to be picky, hardware's not ope (Score:5, Insightful)
I just want to know how to talk to it properly so I can make it do what it is supposed to do (and push it to its full potential).
My microsoft optical mouse might have code in a little embedded processor inside it (I dont know) but regardless of how it works, what matters is that it talks over USB and it talks using a known documented protocol (so any operating system is able to use it).
My Intel Pentium IV 3.4GHz HT CPU does contain microcode that I dont have any source code for. But, it doesnt matter since the documentation of how to talk to it (the x86 instruction set) is open. (I dont know if the physical specs of how to talk to it and how to build a motherboard for it are open though)
Its the same with graphics cards. We dont want or need the origonal design files for the custom ASICs used on the cards. Or the complete schematics for the cards. All we need is details of how to talk to the card and how to get it to draw stuff on the screen. (which these days means full hardware accellerated 3D being powered by OpenGL) If a manufacturer can provide a graphics card where the hardware interface is open and which supports all the things you need these days for games like Doom III, Unreal Tournament and Neverwinter Nights (like pixel and vertex shaders), I for one am prepared to put my money where my mouth is and support them.
Parent
Re:If you're going to be picky, hardware's not ope (Score:3, Informative)
Only problem being that a lot of the functionality these games require is actually in the driver, which is very very likely to be closed-source forever. Its as if you want to recreate a full personal com
Re:Screw the FSF (Score:3, Insightful)
Just to pick one obvious example: if someone's running a proprietary video driver, and their network driver is crashing, it's proven in practice to be extremely difficult to distinguish between a subtle bug in the network driver and a bug in the video driver scribbling over memory in the network stack.
Without visibility into the source code for everything running in kernel-space, issues like