Ahh! So much misinformation. I suspect you may be a troll, but on the off chance you aren't, let's just go over this one more time.
I tend to agree. Thankfully, this isn't actually a problem. NVidia just has to write some wrappers for KMS over it's own API, or modify the programs that need access to KMS to use it's own internal API. Either way, NVidia is the one that needs to do this work, and they can as soon as they feel it's worth it. So far, they haven't, and that probably makes sense given that nothing really needs it so far other than slightly nicer boot screens.The way the nVidia driver works is fine and shouldn't be entire rewritten just to satisfy some misguided idealism in the kernel that even Linux Torvalds doesn't 100% agree with.
Technically, not even the proprietary drivers support all OpenGL extensions. But in terms of core functionality, all you are saying here is that the Mesa drivers are still not up to GL 4.1 support yet which is something everyone knows.1. There are no display drivers with 100% KMS support and 100% OpenGL support through hardware acceleration. There just aren't. Look at any given feature matrix for an open source driver that has KMS. There are TODO's and "in progress" all over just about any feature matrix out there pertaining to OpenGL, 3D, hardware support, or direct rendering support. All of these are vastly more important than KMS.
Uhm, ok. This was kind of a random anti-ATI rant there, which doesn't have to do with anything. But you are entitled to your opinion.2. ATI's support for Linux had been abysmal until AMD acquired them, then it started improving, slowly, while some lines of their GPUs now work like they should, most still don't, whereas nVidia's driver pretty much supports their entire line, and if it doesn't, their legacy drivers do. Thus ATI is still not a choicest option for Linux, still far behind nVidia
Right, you don't like ATI. Moving on...3. Catalyst's support was bad enough, and its release schedule too slow, to the point that many distributions, Arch and Fedora included, just outright stopped supporting Catalyst, and still don't.
He was either lying or mistaken. Or, my bet, he was misleading and you interpreted incorrectly (as you were meant to do). You can believe whatever you want, but the proof is right there in the kernel source code. There is no grey area here, he was just plain wrong if he said that.4. On nVidia's own community forum a module developer came on and said exactly what I did about why KMS is not supported in the nVidia driver, and it was entirely because the KMS portions of DRI explicitly do not allow binary blobs to use it. Almost everything else in the kernel allows binary blob access, except DRI and especially KMS.
That was true in the past - these days I think it's more about performance than missing features. Also, the whole point of the proprietary drivers is to use the same code they have on Windows - if they have to rewrite the whole kernel layer it becomes much more expensive to maintain a Linux port.5. The reason nVidia provides their own DRI is because the kernel's DRI is not capable of things that the nVidia driver takes advantage of, not because DRI is GPL-only.
This is a common mis-perception. There are 2 types of KMS - the kind where it stands for "Kernel Mode Setting" and the specific implementation of KMS that mesa uses which they just called KMS. Wayland requires the former - which means modesetting and memory management needs to be done within the kernel. NVidia and fglrx have both been doing that for years in their own proprietary KMS systems. There is no reason that Wayland can't use the NVidia KMS or ATI KMS systems in their kernel modules, that just has to be coded. It probably doesn't make any sense to do so from a monetary or maintenance standpoint until Wayland is closer to being released.6. Anyone can easily go to the Wayland website and see it explicitly say it *requires* KMS. Because of this, coupled with the fact that KMS-enabled drivers have lackluster OpenGL/DRI support, assures that it's not going to replace Xorg until the DRI developers' phobia of binary blobs can be overcome.