Proposals To Split KMS & GPU Drivers, 2D Kernel API

[asdx]

Closed source drivers SUCKS...

Indeed, I hope proprietary drivers break and they never appear again in Linux.

Same with flash, skype and all the other crap.

[asdx]

Well, nouvou simply doesn't work for me.
Can't set a resolution. Artifacts. Crashes. I had a hard time to even install the binary blob because nouveau permanently crashed.

However, I just love KMS. So i think it would never be a loss to make it possible to be implemented in closed source drivers.

Anyway... my question is still not answered.

Have you tried reporting bugs to nouveau developers?

Please report issues, so they can be fixed.

[b3nn0]

All these highly qualified comments everywhere..
Personally, open source drivers cause a lot more problems for me. Including crashes, low performance, loud fans, artifacts, etc...

I would love to see good open source drivers. But right now, they just can't compete to the proprietary drivers in a technical sense.

EDIT: asdx: I have reported bugs from time to time. But with my new GFX card, it's just impossible to do so. Even simple stuff like using "dmesg" results in crashes from time to time. I can't even gather information I could report (And well, according to http://nouveau.freedesktop.org/wiki/FeatureMatrix most of that stuff is not even supposed to work on the later fermi cards yet. So I guess the developers are aware of the problems. Having a new GTX 570, btw).
Refering to KMS and multihead mostly. Just for information: I was using Oibaf's PPA for the latest Mesa.

[asdx]

All these highly qualified comments everywhere..
Personally, open source drivers cause a lot more problems for me. Including crashes, low performance, loud fans, artifacts, etc...

I would love to see good open source drivers. But right now, they just can't compete to the proprietary drivers in a technical sense.

So do something about, do some bug reporting at least.

Or quit complaining.

[b3nn0]

asdx: We posted at about the same time. See my EDIT: in the post above.

[siride]

Indeed, I hope proprietary drivers break and they never appear again in Linux.

Same with flash, skype and all the other crap.

Yeah, I wouldn't want to be able to actually use the computer to get useful things done. It's more important to just use broken and worthless free software just so that you can say that you're using it.

[hal2k1]

Would this also allow to implement KMS in closed source drivers?

Anyway, I always wondered how it could be "impossible" to implement KMS in the proprietary drivers. Maybe someone can help me with that.

Shouldn't it always be possible to implement KMS as a thin wrapper around a closed-source shared library? Why should it be impossible to implement this in closed source drivers? I really can't imagine a way how this is possible...
(Note: I have never looked at KMS code or something like that. I tried to, but diddn't understand to much of it, as I'm not a driver developer).

AFAIK, KMS is Kernel ModeSetting. The video mode is set when the kernel first loads and runs. Hence the KMS driver has to be an actual part of the kernel, it cannot be a loadable module which the kernel only loads later.

Closed source drivers are bunary blobs which are wrapped in an open source wrapper and loaded after the kernel has started as a kernel loadable module. Too late for KMS.

The only way that one can have a KMS driver is to include it as a part of the kernel itself. Hence the module must be GPL licensed. Hence it canot be a closed source blob.

[Nille]

And why are on my System i have kms as Modules? And why i see the first output not with my nativ resolution and why he switch after loading the modules?

[faustop]

The only way that one can have a KMS driver is to include it as a part of the kernel itself. Hence the module must be GPL licensed. Hence it canot be a closed source blob.

Yes, but this opens the great possibility of companies like AMD and Nvidia modifying their binary blob driver to be only a GPU driver while using the same GPL KMS driver as the opensource drivers. This would be possible and desired because:

• The KMS code could became more stable/mature, gainigng more users and developers
• Companies would be able to keep their precious GPU code* closed, while sharing work with the community on the more basic mode setting code;

* Companies have stated in the past that they wouldn't be able to opensource their drivers even if they wanted because they contain code/technologies liscenced from other companies and not belonging to themselves. That is one of the reasons AMD started a new driver from scratch when they decided they needed an open source driver a few years back.

[hal2k1]

Companies have stated in the past that they wouldn't be able to opensource their drivers even if they wanted because they contain code/technologies liscenced from other companies and not belonging to themselves.

This is the precise reason why we do NOT want to run binary blobs from AMD or Nvidia.

That is one of the reasons AMD started a new driver from scratch when they decided they needed an open source driver a few years back.

Nitpick: AMD did not start a new driver, they merely published programming specs. Here they are:

http://www.x.org/docs/AMD/

The Radeon open source driver is code written from information (facts documented in the above programming spec) by community effort (including some input from AMD employees) and hosted at Xorg. This code belongs to the community, the community holds the copyright, not AMD. In this respect this open source driver is not like the Intel open source driver. The Intel open source driver is written by Intel, owned by Intel, the copyrights are held by Intel. The equivalent scenario is NOT the case for the Radeon open source driver, this driver does NOT belong to AMD/ATI.

Hence, code/technologies liscenced from other companies have no impact at all on the Radeon open source driver.

This is a very, very important point in the context outlined in the first statement from you quoted above.