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?"

Comments

Come on

[liliafan]

Obviously it would be nice if nvidia and ATI would open their drivers, the opensource community would benefit hugely from such a move, I also think the chip makers would benefit from it in terms of code improvements and fresh ideas....I don't see it happening anytime soon though, there has been calls in the past for drivers to be opened and it hasn't happened yet.

As for this statement:

For Nvidia, intellectual property is a secondary issue. "It's so hard to write a graphics driver that open-sourcing it would not help," said Andrew Fear, Nvidia's software product manager. In addition, customers aren't asking for open-source drivers, he said.

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

[Ravenscall]

There have been dozens of calls over the years for drivers to be open sourced!

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.

Re:Come on

[drooling-dog]

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.

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 system is open source. What is important is the ability to package and deliver an OS that works out of the box, without proprietary encumbrances and without requiring users (especially the less technically adept ones) to fish around for drivers before they can boot their systems.

Re:Come on

[Halo1]

And now with proper formatting:

Previously, they used other arguments:

From: Jon Smirl
Date: Mon, 25 Oct 2004 23:55:58 -0400

After talking to representatives of both companies, it seems that the
patent system has completely perverted the IP situation between them.
But are staying secret because of fear of being sued by the other for
infringement. This is exactly the opposite of what full disclosure of
patents was supposed to achieve.

I wish they could just get together and agree not to sue each other
over stupid things like register designs and programming models. The
designs are horrible on both cards due to accumulation of historical
cruft. Save the lawsuits for the core of the engines if you really
have to sue each other.

--
Jon Smirl

Re:Come on

[TheLinuxSRC]

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?

Re:Come on

[walt-sjc]

Nvidia already needs documentation in order to write drivers. Releasing documentation that they already have would cost them VERY VERY little.

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.

Re:Come on

[jawtheshark]

The simple fact that FOSS developers have not been able to produce good GPU drivers despite reverse-engineering demonstrates the level of complexity involved.

Have you just considered for two minutes that it's not the implementation that is complex, but the reverse engineering. Reverse Engineering is pretty much trial-and-error. It's guesswork... Imagine the OSS developer could get hold on the full specifications, then I'd imagine that the "level of complexity" would go down seriously. Actually, as far as I know, NVidia gives the specs of the 2D features of their cards (don't quote me on this, I might be wrong), resulting in strong Open Source drivers for that aspect of the card. Pretty much every NVidia card I have owned worked fine with the Open Source "nv" driver as long as you stay in 2D world.

Re:Come on

[Bitsy Boffin]

You are very naieve. For Nvidia to open source thier code would cost them a significant amount of time, money and quite possibly customers if they didn't do it right. Just off the top of my head...

• Paying an army of lawyers to ensure that they CAN release in the first place. I'd bet that they don't have clean rights to distribute the source to everything in thier code, bet they licence some stuff.
  
• Paying more lawyers and consultants to work out the best licence, or more probably write thier own.
  
• Paying thier developers to clean up the code base before release, package it, setup version control access for the public.
  
• Paying thier developers while they now unquestionably spend time liasing with the new open source developers.
  
• Paying thier support staff when people using modified drivers ring up because stuff isn't working.
  
• ...
  

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).

Re:Come on

[networkBoy]

Most important:
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

Re:Come on

[Dr. Evil]

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.

Re:Come on

[ThePhilips]

...millions more happily use thier products without a problem.

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. Piece of junk hardware might just happen to work - but drivers may be just plainly broken.

Another point people are pursueing - and I am 100% with them - is that hardware *must* be open. Just of situation when you buy a hammer with driver. How many chances hammer would break? How many chances that driver will break with next OS upgrade? IANAL, but some "interoperability" bells are ringing inside of me. IOW, hardware manufacturers may not be allowed to dictate how and for what purpose their products are used. In that situation, having Open Source Driver is must.

P.S. The "Open Source Drivers" campaign has no future. I would gave my vote to "Open/NDA-free Documentation" campaign. Documentation is what really matters.

Re:Come on

[???]

For Nvidia, intellectual property is a secondary issue. "It's so hard to write a graphics driver that open-sourcing it would not help," said Andrew Fear, Nvidia's software product manager. In addition, customers aren't asking for open-source drivers, he said.

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.

Re:Come on

[fuzzix]

The drivers are open source (just extract the block from the NVIDIA.sh); it's just that they are not free software.

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.

Re:Come on

[printman]

In many cases, hardware vendors simply do not produce the kind of documentation that you would need. The hardware and software developers work together, so there is a lot of undocumented internal knowledge that goes into those drivers.

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! :)

Re:Come on

[NutscrapeSucks]

So, what are the video card's products? Are they the hardware cards or the drivers?

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.

Re:Come on

[Znork]

I'm sure writing a graphics driver is very complex, but fixing bugs in one isnt.

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 drivers arent that much of an exception. Access to documentation being equal, I'd bet you the OSS version would be more stable every time.

But hey, I'm sure the proprietary driver would be much better 'optimized' for Quake and 3dmark.

Re:Come on

[Stephen Samuel]

Reverse engineering a complex piece of hardware is not easy. It takes time and energy that would be far better spent just writing code. Many years ago I tried to reverse engineer driving of a serial chip. I spend days working on it before I realized that I could go down to the store (this was pre-web) and get the spec sheet for the chip. (Turns out it was a 6551)

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.

Re:Come on

[Hast]

What do you mean "massive FPGAs"? From my own experience with FPGAs and GPUs the two are not at all similar. And FPGA is just that, a "programmable gate array" where you can alter pretty much everything programmatically.

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 with it. Those use the fact that a modern GPU has a shitload of processing power as each fragment (pixel) shader typically has 4 floating point ALUs which can be operated as vector processor. That is done by uploading shaders to the GPU which are then executed there.

Or do you mean that shaders are like a limited programmable array?

This is with my experience as someone who has worked with FPGAs and GPU shaders. (But nothing relating to GPU drivers.)

Why not?

[tomstdenis]

Linux should be *open* to using either. If not than it's not really a "open" tool.

The real question is: Should we buy hardware with closed source drivers.

Tom

Re:Why not?

[Homology]

This is why people argue that the BSD license is more open than the GPL. However, the restriction against linking with proprietary code is what ensures that certain free software actually gets written. It's a means to an end that ultimately results in true openness.

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

[Ravenscall]

Useability beats ideology. I want my GeForce to work, I will use the drivers that work, regardless of license.

Re:Sometimes

[DeathPenguin]

And not only that, but I want my $300 graphics card I bought to play UT2004 and Quake 4 on to perform like a $300 graphics card. This is one area where nVidia's proprietary driver hasn't been touched in the past five years or so. The driver not only works (For most), but it works about as well as the Windows driver.

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 mentioned, we may as well have the freedom to choose both--Just don't cry to the kernel developers when a proprietary driver breaks something.

Re:Sometimes

[Billosaur]

Useability beats ideology.

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.

Re:Sometimes

[Just Some Guy]

Useability beats ideology.

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.

Re:Sometimes

[AvantLegion]

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.

Don't even joke like that. I don't think I could handle TWO Stallmans.

Wrong way around

[Whiney Mac Fanboy]

From the TFA:

"If Linux expects broader vendor support, the community needs to capitulate to proprietary software involvement," said Raven Zachary, an analyst at The 451 Group.

Zachary gets this the wrong way round - instead, he should say:

"If vendors expects broader Linux support, they needs to capitulate to free software needs"

This is (yet) another way Linus has misunderstood a legal, rather then technical challenge (along with GPL v3 & the bitkeeper fiasco).

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 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

[tomstdenis]

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

Re:Wrong way around

[jdcook]

"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."

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?

Download them

[Foofoobar]

As long as them drivers are free and have no limitations on being distributed with a system, there shoukldn't be a problem. Elsewise, leave them out and just download them.

As others have pointed out...

[agraupe]

Yeah, it's great to be an idealist, but there are some of us who want usable 3D. I fall squarely in the latter category, and I will continue to load proprietary modules into my kernel.

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

[Moby Cock]

If a Linux Distro is really open, should the user not have the freedom to choose if he wants to use open-source drivers or proprietary drivers. Being slavish to the 'open-source only' rule is in fact counter to the spirit of it all.

Oh goody

[BenjyD]

Oh goody, another licence flamewar. Seriously, proprietary software is going to be a fact of life for ever, intentionally annoying your users by preventing them using binary modules is only going to reduce Linux uptake.

The kernel should offer API's, no more and no less

[scsirob]

The Linux kernel offers API's and services that allow proprietary applications to run. If you look at a video driver as an "application to display information" then I see no reason why a proprietary driver couldn't be used with the Linux kernel. Just stick to a well defined set of API's and this discussion becomes a non-issue.

Open Graphics Project

[Theovon]

The Open Graphics Project recently released schematics for their first product and are steadily making progress towards completing it for sale (http://kerneltrap.org/node/6262). If Libre graphics drivers are REALLY important to you, you might want to consider looking them up at "www.opengraphics.org". Despite being unfunded since early 2005 (which they could use some help with), they are still managing to make some headway. Those people with technical expertise (graphics drivers, graphics hardware, PCB design, chip design) would do well to pitch in to the effort. And those with money who also complain about the lack of Libre drivers should put their money where their mouths are. Rather than sitting around and complaining about it, the founders of the OGP decided to actually DO something about it; if you want to do more than just complain, they could use your help.

Re:Open Graphics Project

[ledow]

OGP seems a brilliant idea but without significant financial backing from a major player (nVidia, ATI, IBM, someone like that), it's basically just a hobby project. Who is going to back a piece of electronics on which they have no IP and which ANYONE, even say nVidia or ATI or some bloke on eBay, could copy and sell?

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.).

Not in my kernel

[ettlz]

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.

Re:Not in my kernel

[Anonymous Coward]

Binary drivers are generally just crap ... look at the stability problems they cause with Linux. Even *if* they were good, they should never be accepted because they are unmaintainable. The OpenBSD people seem to be a really forward-looking bunch. It annoys me that so many in the Linux community have such short-sighted and highly flexible ideals, because it is Linux (not OpenBSD) that sets the standard for free and open source software ... and they aren't setting the standards very high. ATI and NVidea deserve to be marginalized as Linux gains market share ... let a company that freely provides technical documentation (as anyone selling a product should) get some dollars. I'll cheerfully accept a video card that is theoretically 50% as fast if it has the complete and stable drivers that result from good open documentation.

Who cares? The kernel license has an exemption.

[Anonymous Coward]

So it doesn't matter what people think about it. It is allowed... move on. NVidia and ATI will never release open source drivers that have the same performance as their proprietary closed driver so what does this matter? If Linux wants to survive in the 3d performance arena that require high performance video cards then it has to allow proprietary drivers otherwise it is screwed. If the Linux kernel changed to not allow any proprietary drivers to ever link in any way with the kernel then Linux desktop use would be reduced dramatically. I have been using it for 9 years and 5 years exclusively on my desktop without Windows but I would drop it in a heartbeat if the latest 3d games and 3d modelling software that normally get released for Linux wouldn't have about same performance as a Windows setup. If MS wanted to severly hamper Linux growth it would be relatively simple... buy NVidia and ATI and stop releasing drivers for Linux :). Some might say that the server market would keep growing the same but that would not be true because without 3d performance I bet that quite a few developers would stop producing code for Linux which in some way or another would also eventually slow server ocde development(less people with the skills on Linux).

Re:Well, since it's a proprietary card...

[nagora]

This is why you'd want the video drivers written by the OEMs.

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

Support open gpu hardware.

[AHuxley]

Help build and support a real open solution. http://opengraphics.org/

If closed source drivers, then open platform

[omegashenron]

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.

Re:The kernel should offer API's, no more and no l

[bfields]

The Linux kernel offers API's and services that allow proprietary applications to run. If you look at a video driver as an "application to display information" then I see no reason why a proprietary driver couldn't be used with the Linux kernel.

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 kernel itself and muck around with its internals quite a bit; they no longer communicate purely over well-known stable APIs.

Re:If you're going to be picky, hardware's not ope

[jonwil]

I dont want to know how it works.
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.

Older nvidia cards...

[LDoggg_]

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?

Snappy Answers to Stupid Questions

[npsimons]

Q: Should [GNU/]Linux Use Proprietary Drivers?

A: No.

A little more seriously, let me just repost part of a comment that really illustrates the veracity of this answer:

And really, I don't know when you started to use [GNU/]Linux, but when I
started (pre-1.0) we didn't have video drivers. We wrote them ourselves.
We chose the freedom of [GNU/]Linux over the convenience of binary-only
platforms with working drivers. It shames me that so many of the current
generation of [GNU/]Linux users don't understand what the world before
[GNU/]Linux was like. It was hell. Closed source binary-only drivers
everywhere. Buggy code that you couldn't fix. [GNU/]Linux changed all
that. Finally we have source and freedom and rights. Finally there's
something to be proud of; an entirely open source operating system built
through the sweat and tears of 1000s of volunteers. And you would
sacrifice all that for slightly faster 3D graphics? I can't comprehend
your state of mind. Your priorities are completely foreign to me.

(seen on slashdot, not said by me)

Re:nVidia exec is retarded

[aesiamun]

Lame is better than Fraunhofer?

no...not really.

Firefox is better than Opera? Once again, I disagree.
Gaim is better than Trillian? Not on my windows desktop.

You're basing fact on your opinion. Stop it.

Or buy VIA

[metamatic]

I have an EPIA M10000. Next time I build a PC, I'll probably pick another VIA EPIA. Why? Because VIA released source code for drivers for every piece of hardware in the system, from the S3 UniChrome graphics card to the hardware MPEG decoder, from the ethernet interface (hello, nVidia) to the hardware random number generator.

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.)

Re:If you're going to be picky, hardware's not ope

[ardor]

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.

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 computer with a state-of-the-art OS on it, but only get the schematics of the hardware, with NO software whatsoever. This will take a while, especially since the closed-source stuff is filled with tons of functionality and is being extended at an enormous pace.

Re:Screw the FSF

[MenTaLguY]

It is also a pragmatic issue; heavy user reliance on proprietary drivers would make Linux development unsustainable.

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 that turn out to be extremely labor-intensive to fix and diagnose. We don't have that kind of labor available. And of course if the issue's in the proprietary driver, the kernel developers can't fix it anyway.

A pragmatism that ignores consequences isn't much of a pragmatism.

Jumping out a window might be a "pragmatic" way to leave a building, but most people would agree the pragmatic solution would be to take the elevator to the lobby and use the front door instead.

Yes.

[TheQuantumShift]

And lo, stuff started working correctly, out of the box, with no makefiles involved. And it was good.

GPL over the users

[Enrique1218]

I find this fanaticism in the open source community is what's crippling Linux. OMG, some are actually considering using code in the kernel to block proprietary drivers. Imagine the problems that is going to cause for the end user. That's insane, but that is the mentality in the open source community that puts the GPL over the user. The gpl purpose is to foster cooperation not to force it. If an entity believe its needs to protect its IP, then why does that preclude their software from operating with GPL software. Majority of users (99%) want something that just works. They don't care about proprietary, open source, or philosophy. They don't have a CS degree nor care to get one. They don't even read the EULA. They just want the function which coincidentally is the purpose of making software. The end is function! The end is the user! GPL is just a means to get there but it is not the only way.

Re:GPL over the users

[KayosIII]

Well actually it is that fanaticism that started gnu in the first place and is still a driving force behind it, Many of the people involved would rather have an open system that works less well (you see these are not just things as you see them now but also as they will potentially grow in the future). Binary only drivers could potenialy take effective control of the linux operating system out of the communities hands. A lot of people out there still remember what happened to unix. Binary only drivers also cause lots of everyday mundane problems with kernel development too. It is impossible to properly debug a kernel running binary only modules, or to guarantee security. Having said that - I don't think the current players are trying to take control of the kernel or anything like that. I would not be that grateful if binary only modules where completley removed. There are a whole bunch of practical reasons why opensource drivers work better under linux... In the current situation opensource drivers ultimately take less work from the user, products based on opensource drivers (or standard hardware drivers) have a much longer lifespan. Ultimately I would like to see a carrot rather than stick approach. Having opensource drivers *Is* a big selling point for me. I would like to see in the future boxes with *open driver quality assurance* written on them. This would be the second largest selling point for me after - will the device perform the job that it needs to. I think I am done ranting

Re:GPL over the users

[civilizedINTENSITY]

Agreed, it is obvious that you don't know what is meant by "Freedom".

The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software--to make sure the software is free for all its users. ... To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights.

If we gain (the use of functionality of a graphics card) by accepting a binary, we lose incentive to develop the code. Short term gain in the functionality of the machine, long term loss. If you really don't get this, I'm not sure how to make it make sense, accept perhaps as an analogy. Binaries are like welfare payments that let a person buy food enough to survive, but aren't improving their chances of getting a job. Sharing code (or at least documentation) is like sending someone to college rather than giving them welfare. You eat in both circumstances, but only the latter case is actually leading anywhere. If all you care about is getting food (or finishing that term paper on time, or getting the quarterly report done) then it doesn't matter.

Users won't be to use their hardware to the full capacity because you want the manufacturers to develop driver according to your rules.

No. Not even close. Please try again. Consider this: I don't want manufacturers to be developing drivers at all for Linux. Rather I would like to see the information made available so that anyone who so chooses, and who is capable, can develop drivers. Whether the hardware is able to be used to its full capacity depends on how good those drivers are. Note the similarity to the analogy: if given the choice between welfare or a job, I'll take the job.

Being force to use Windows and being subject to Microsoft abusive monopolistic practices because your job requires a functioning computer and Linux takes too much time and effort to get it to work.

No. Not even close. Also offtopic. Still, for fun, you are saying that you will be forced to use Windows? Solaris & OS X & BSD don't exist? And this is because Linux is "to hard to get to work"? Are we still talking about drivers? Linux certainly appears to be as easy to install, and once installed updates are easier and software installation is easier. Not as easy, easier. Where else can you pick from a list and have 1000s of applications suddenly downloaded and runable? This is easier than driving to walmart.

GPL is the only reason Linux is on map and not another BeOS or OS/2. Fine, I concede that, but, the open-source community should not look to cut out proprietary vendors.

Two excellent products that were better and it just didn't matter. However, the open-source community doesn't want to cut out proprietary vendors. Rather, they want to cooperate with them. It is the Free Software community who thinks that locking code up today will result in a tomorrow, eventually, where everything is locked up. Thus, the insistence on behavior that will avoid this loss of freedom. You might not have all the functionality of your graphics card this decade, as part of a struggle to make sure you have access to a codebase of Free software forever.

Good useul software is sometimes closed. Leave it to the end user to decide if that is a problem.

Sure, no problem. Just don't link it staticly or dynamicly with GPLed software. It isn't a problem unless you want to have your cake and eat it too. Then it *is* a problem. I'll even admit I own a fairly current license for Mathematica for Linux(,though it isn't installed.) However, I used Octave when I was paid to do research and could choose my own tools. This makes sense to me.

DRM is fact of life and entities have a legitimate copyright to protect their right. It is a fundamental foundation of our societ

not allowing proprietary drivers is a mistake

[efalk]

Not allowing proprietary drivers to use Linux is a huge mistake, and imho contrary to the philosophy of free software.

Stallman says that the 0th law of free computing is that I own my computer. And he's right. I *do* own my computer, and I own my video card as well. If using a proprietary driver is the only way to use my video card on my computer, then who are the Linux community to tell me I can't? Or to even make it harder for me?

The fact is that Linux's hostility to third-party drivers -- even open ones -- is a huge detriment to the operating system.

Linux should take a lesson from Solaris and establish a standard interface which allows anybody to write a driver, open or not, and have it be binary-compatible with the operating system. Under Solaris, it was possible to create a single binary driver and have it run unchanged under Solaris 7, 8, 9, and 10. My understanding is that Linux deliberately cripples binary driver compatibility just to make it harder for anybody to ship pre-compiled drivers. That's the behavior I'd expect from a cell phone company, not an open operating system.

Also, for the record, I've written video drivers for ATI cards for a living (Solaris). They're insanely complicated; with literally thousands of registers. Reverse-engineering would never reveal the full complexity of the hardware.

As for documentation, the documentation I've worked with (from more than just one video chip vendor) is almost always woefully incomplete. It doesn't work to "just release it"; it really does involve a lot of cleanup or phone support with the people trying to develop software. Remember that the documentation is written by and for people who can just get up and walk down the hall if they have a question. Once you start supporting third-party developers, it can be a nightmare.

The FSF is full of it

[Zan Lynx]

Where do I fall on it? The FSF is full of it when they say that you can't write a proprietary binary that links into GPL software.

The only thing that the GPL can control is derived works. If the work isn't derived, it isn't under any sort of GPL control.

Now, creating a module that can link statically or dynamically without it being derived IS a tricky thing. But it can be done.

If the interface is well documented, the code creation trail is legally clear, and ideally it works unmodified on at least one non-GPL code base, the module cannot be derived from GPL code and the GPL doesn't apply. At all.

I'm not sure ATI or nVidia's modules qualify but they are close.

Actually distributing a static linked binary containing GPL code would probably be a GPL violation. (Note that nVidia's binary doesn't contain GPL code, and "magic numbers" from header files are not copyright, any more than the same sort of information taken from Windows headers taint WINE.)

Distributing a non-GPL-derived dynamic linked binary, or a binary with end-user compiled glue code would not be a GPL violation. The end-user just happens to dynamically link it to GPL code, or compile it with GPL code, but that is his right under the GPL and not the distributor's problem.

I am not a lawyer, etc, etc.

Pushing the rope

[Simprini]

The card manufacturers insist that open sourcing the drivers lets valuable IP out into the open that could hurt their business. True or not, that's the company line and they aren't going to change it. I fall into the category of "I want my damn video card to work". And I want it to work with all it's bells and whistles. The solution is that I taint my kernel by installing the Nvidia drivers. I sleep just fine at night having done this dirty dirty thing. But every day I wake up and get 3D acceleration across both of my monitors and it makes me happy. I'm staunchly in the middle of the road on this one.

Well ..

[Anonymous Coward]

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

Well.. has he get the driver code yet ?

RMS/FSF failed, still no driver

[AHumbleOpinion]

"Useability beats ideology."

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.

No proprietary drivers

[Brandybuck]

I don't use Linux, so it doesn't much matter to me if it uses proprietary drivers or not. But I do use FreeBSD which has a proprietary driver or two available for it. My answer based on my FreeBSD experience is: "NO FSCKING WAY!"

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!