DRM Changes Coming Up For Linux 3.1 Kernel

[89c51]

If there is enough potential revenue behind it to make it worth the investment.

i was hoping you to know more since you work at amd and probably interact with the blob people but thanks anyway

[smitty3268]

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.

Again, I said nothing about the licensing of KMS, just the licenses KMS would allow. And the ONLY reason KMS won't allow binary blobs is because of political decisions and nothing on any technical merits whatsoever.

This is not true at all, and there have been plenty of posts here showing you the proof. The KMS entry points are not marked GPL only, and you can look directly at the source code to verify this.

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.

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.

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.

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.

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

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.

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.

Right, you don't like ATI. Moving on...

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.

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.

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.

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.

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.

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.

[jrch2k8]

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

first WTF? then WTF? and do a for to infinite of WTF?'s here is some explanation after you are done.

1.100% totally BS you are as wrong as is humanly possible here, KMS have absolutely nothing to do with openGL and openGL have absolutely no relation to KMS per se.

ttm/drm and kms are important mostly to the driver internals to handle stuff like modesetting, memory management and physical hardware access in a modular maintanable fashion as the driver foundations not opengl. and is very hard to achieve high performance drivers without them and yes nvidia use all those systems but their own not the one in linux kernel, what the hell do you think they have in that monstrousity of kernel module? logos? supermarket list? porn?

Opengl is handled by "!!!MESA!!!" and mesa needed a major overhaul before even think in implementing anything beyond GL 1.x, so right now all that is in the past and opengl support is catching up fast enough if you considere only 4 guys are working in it next mesa stable will have GL 3.0 or superior since many of the parts are already there

2. yes fglrx suck pretty bad

3. yes fglrx should be illegal by constitutional's level laws worldwide

4. read the code dude that is not the issue, at least not now dunno some years ago

5. wrong again lol, nvidia doesn't have the ultimate power ranger level dri code and dri is not Opengl just a layer in between. of course nvidia have years and 30+ developers maintaining that code so you can ovbiously expect a bit more optimized code path here and there and maybe some goodies here and there (or dirty hacks depending the version) to achieve a bit more but is nothing as abysmal as you think.

probably the major performance difference you can find between nouveau and nvidia blolb here is a 10% difference cuz the big fat performance difference in their libGL implementation compared to Mesa's since mesa is working first in features to later focus on performance (remember there is only 4 guys not 30+ like nvidia) so is natural in this early stage (linux graphic stack is right now like in pre alpha state once in a couple of full releases when reach some sort of beta stage the performance diff wont be that big anymore)

6. yes it requires KMS and nvidia blob have it too, the only missing part here is that their KMS code is closed source and so wayland folks can't magically figure out how the hell use it. probably nvidia when wayland goes production ready in important distros they will write their own glue to between wayland and their blob and problem solved. they just wont rewrite 20% of the driver to use the linux native KMS code when they can use/improve theirs already in the blob and just glue wayland later

last advise wikipedia and freedesktop.org are free you know and you can download the kernel sources for free too duude or at least if all this is beyond your understanding many ppl here are willing to help you understand if you ask nicely with a lower tone