DRM Changes Coming Up For Linux 3.1 Kernel

[Jonno]

I didn't say that KMS or DRM was GPL. Reread what I said, I said they were GPL-only, as in they explicitly won't allow the use of binary blobs

That is verifiable non-true. No KMS symbols are exported as EXPORT_SYMBOL_GPL, they are all exported as EXPORT_SYMBOL, and can thus be used by NVidias blob if they so choose.

[Yaro]

Which other parts of the kernel do you think should not be GPL-ed so huge multinationals can have a bit less work?

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

This, and pretty much your entire post, is false.

Everything I said was true:

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.

[Yaro]

That is verifiable non-true. No KMS symbols are exported as EXPORT_SYMBOL_GPL, they are all exported as EXPORT_SYMBOL, and can thus be used by NVidias blob if they so choose.

So the nVidia developers were lying when they said this, then?

[del_diablo]

Does there exist a mega corporation that does not lie? Nvidia is no exception.

[smitty3268]

So the nVidia developers were lying when they said this, then?

It wouldn't be the first time.

No, really, that's a matter only lawyers could decide. If they think that the KMS code is tied too closely to the kernel and that any way of using it would be considered extending the Linux code, then that would bring the kernel GPL code into their driver. However, there is nothing that can be done about that. The linux kernel devs can't just suddenly relicense the entire kernel.

On the other hand, if NVidia can come up with an abstraction layer that works across kernels, then it would fall under the exact same situation that all the other kernel APIs it use are under - which means it would be allowed.

I suspect what NVidia really means is that they can't use the KMS kernel layer directly without first creating a portability layer on top to protect them from the GPL, and they consider that too much work to do. Besides, they already have a working system and don't want to have to recreate that whole thing using a new API. So the licensing issue is a convenient excuse to people like you who might ask them to do so.

PS - Wayland can call directly into the nvidia/fglrx blobs just as easily as it can into KMS, so that is not a blocker. Well, assuming the APIs are publicly known, but in the worst case I'm sure AMD/NVidia could provide the necessary code themselves.

[droste]

So the nVidia developers were lying when they said this, then?

http://pastebin.com/evjRZfsb

[agd5f]

The proprietary drivers share a lot of code between OSes. KMS is Linux only at the moment, so it doesn't make sense to use it if you want to maximize the amount of code you can share. Without a lot of code sharing, supporting Linux does not make much sense considering the size of its market share. If there were large revenue potential tied to KMS support you'd start to see support, but until then, it's just extra work with minimal benefit.

[89c51]

The proprietary drivers share a lot of code between OSes. KMS is Linux only at the moment, so it doesn't make sense to use it if you want to maximize the amount of code you can share. Without a lot of code sharing, supporting Linux does not make much sense considering the size of its market share. If there were large revenue potential tied to KMS support you'd start to see support, but until then, it's just extra work with minimal benefit.

KMS is linux only but do you see proprietary drivers supporting openwf at some point???

[pingufunkybeat]

Binary blob drivers do all their memory management and modesetting in kernel space. They already have "KMS", it's just not the open source KMS which is used by Mesa drivers, but their own closed-source re-implementation.

They have their own implementation because it makes it easier to use Windows drivers under Linux. They write drivers primarily for Windows, but keep them clean enough that with some simple wrappers, they will work with the Linux kernel. Rewriting their drivers to use proper kernel mechanisms would be far too much work. What you are demanding is that the kernel developers donate a closed or closed-source-friendly implementation of the low-level part of the GPU driver. This is silly, since nvidia already has a much more optimised in-house version of that.

Linux is a GPL kernel. That's a good thing, and if you don't like it, there are other kernels you can use.

[agd5f]

KMS is linux only but do you see proprietary drivers supporting openwf at some point???

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