Open nVidia Linux Driver Pledge Nearly Complete 221
Ciarán Mooney writes to let us know that the Pledgebank drive to raise $10,000 for Project Nouvaeu is almost complete — at this moment it needs only 196 more people to sign up. Project Nouveau aims to provide open source 3D acceleration for nVidia cards. The drive was started by David Nielsen, whose blog explains what he hopes will happen.
This is a worthy cause (Score:5, Informative)
Also Fedora 7 (dure April) intends to include the nouveau drivers - which is great as out-of-the-box Fedora can't include the binary nVidia driver necessary to have AIGLX working.
And to anyone who thinks this is unnecessary as there is the binary driver - just wait until you card is dropped from the official support and the old driver stops working with some future kernel.
Re:Excuse me. (Score:3, Informative)
They don't need money... (Score:5, Informative)
Congratulations to everyone who pledged to throw money at something that doesn't need any.
Re:This is a worthy cause (Score:2, Informative)
just wait until you card is dropped from the official support and the old driver stops working with some future kernel.
Open source drivers drop support for devices too. And unless you're a kernel module developer, you're just as much at the mercy of others as you are with a binary driver from the manufacturer.
Besides, isn't patent licensing part of the reason nVidia and Ati won't release fully OSS drivers? I believe Intel has patents on certain memory bus related technologies which are used by both nVidia and Ati.
Re:Huh? (Score:4, Informative)
Re:Huh? (Score:5, Informative)
Re:What is wrong with the proprietary driver? (Score:5, Informative)
Now for me that wasn't much of a problem. I sighed, logged in as root, found the original installer I downloaded from NVidia, ran it, agreed to the license, pressed continue and was greeted with a message about missing kernel headers. Sighed again, downloaded linux-headers-`uname -r`, reran NVidia installer, etc, etc, ad nauseum every time I update the kernel.
As I said, I know why and how I do this but not everyone does and the whole point of bringing true open source 3d graphics to the desktop for Linux users is so they don't have to learn how or why they need to do this.
Re:Huh? (Score:3, Informative)
nVidia Linux Drivers support x86-64 (Score:3, Informative)
You are either misinformed or a liar. The nVidia Linux drivers support x86, x86-64, and IA-64 architectures. This is actually one more architecture than they support on Windows (no IA-64 for Windows systems).
I agree it would be nice to see open source replacements for the nVidia drivers, but please lets not spread or further any FUD about the current closed source drivers. nVidia has done a nice job with the drives. I use them without issue on two different x86-64 machines (one AMD, one Intel).
Re:nVidia Linux Drivers support x86-64 (Score:3, Informative)
And, in case anyone wants a reference:
http://nvidia.custhelp.com/cgi-bin/nvidia.cfg/php
Now can we please stop with the BS complaints that nVidia allowed a known security hole to exist in their drivers for two years.
Re:This is a worthy cause (Score:5, Informative)
Re:nVidia Linux Drivers support x86-64 (Score:3, Informative)
Or simply imprecise. To rephrase your parent poster, "one of the problems is that the drivers support the x86, x86-64, and IA-64 architectures only." People on other architectures are out of luck.
Let me start you off... (Score:3, Informative)
You are not going to get a driver in that amount of time.
But, I will give you clues. The nVidia chip is pretty high on the OpenGL stack. The chip itself handles most OpenGL primitive operations. It just won't do contexts (nor will the ATI). I don't know the underlying protocol to communicate with the chip, but I would guess it is packet based. Registers would prove far too slow. I would imagine that for OpenGL, VGA, video, and mode support you are looking at almost a thousand "registers" or eqivalents.
It may be possible to catch the kernel level packet interfaces -- mode setting and VGA extension should be reversable via emulation. But this won't tell you what any of the commands do. You could try iterating OpenGL and comparing generated packets... but...
Modern chips typically DON'T implement a fixed-function pipeline. So you will have to figure out how OpenGL shader compiler for the chip works (because you have to know the "machine code").
Good luck for a 4 week driver project. The shader compiler itself is almost a C++ compiler which has to be reversed, the communications format and the packet streams. I would give 10 man-years as a first estimate.
Or, you could try to get the vendors to "be nice".
But I won't do it for 10 grand. Sorry.