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

[phoronix]

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

Following a "Kernel Display and Video API Consolidation" mini-summit held at the Emebedded Linux Conference (ELC 2012) last week, Linaro and other mobile/embedded Linux stakeholders have come up with several graphics-related action items for the Linux kernel. One of the proposals is to split KMS and GPU drivers in the kernel...

http://www.phoronix.com/vr.php?view=MTA2MDM

[b3nn0]

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

[timofonic]

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

Closed source drivers SUCKS...

[MalleRIM]

Congratulations. You have been awarded with the Most Qualified Comment Award.
I have to agree though, closed source drivers suck. But it's good if they work when you need them.

[b3nn0]

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.

[Nille]

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.

The last news that i read was that the internal APIs for this are GPL Only. And i dont believe that amd and nvidia want to reinvent the wheel.

[b3nn0]

The last news that i read was that the internal APIs for this are GPL Only. And i dont believe that amd and nvidia want to reinvent the wheel.

This should not be a problem at all.
You could always define a thin GPL driver layer (i.e.: A wrapper around the binary blob) that relies on an external implementation.
That the binary blob is the only actual implemenation of that wrapper-interface is written somewhere else...

(To elaborate on that:
NVidia/AMD could write a very thin KMS-enabled "driver" that does not actually drive the hardware but simply call in a (closed source) shared library that does the actual work.
Than KMS-enabled pseudo-driver could of course be open source as it does not include any driver-internal secrets or something like that.
And as I already said, there might of course be problem I do not see right now, as I have never looked at KMS code. I just wonder what those are. "impossible to implement" just seems a bit too far for me.)

[sylware]

First of all, any driver code which runs on Linux *is* covered by the GNU GPL. There is no user land exception for drivers... See Alan Cox mail in the DRI dev mailing list archive, and the GNU GPL linux exception at the top of the kernel tree (the GNU GPL exception is granted only for "normal user programs" above syscalls, and drivers are *not*). Till no significant kernel holder of copyrights decides to sue in order to get the driver code, anybody is allowed to infringe the linux GNU GPL and keep their linux driver code closed.

The current gfx stack is dual licensed: BSD/GPL (personal opinion-->that's why I do not code for it: it is not plain GNU GPL) that's how we will have a close source wince fork of the AMD GPU stack with the discret DMA engines and UVD decoder in order to make the linux driver look like a degraded wince driver (you can be *sure* that microsoft sailesforce *will* leverage this). See the phoronix announcement (that makes me sick). I met many industrials, they all dream of an apple world (=useless opensource core for an optimal close source OS), then going BSD is IMHO far too dangerous and defeat the purpose of getting an optimal 100% open source OS which will stay for good.

Instead of convincing ARM to improve their close source driver, it would be better to convince them to release *all* hardware APIs and help the open source driver: LIMA (https://gitorious.org/lima, unfortunately not cleanly GNU GPL).

GPU hotplug... is a sort of PCI hotplug (external PCIE). With the electrical modulation of displayport being the same than the one of PCIE, we can expect a simple standard PCIE interface set (something like MMIO regs) for display devices (= one driver for all, EDID in the PCIE ROM! )... well except for the GPU DMA engines which will send the display data to the display devices over the PCIE fabric. Thunderbolt *is* a step in the right direction (apple/intel are right on that hardware path).

If the new EDID kernel parser could be protected with plain GNU GPL... thx!

My 2c... totally personal!

[bridgman]

that's how we will have a close source wince fork of the AMD GPU stack with the discret DMA engines and UVD decoder in order to make the linux driver look like a degraded wince driver (you can be *sure* that microsoft sailesforce *will* leverage this). See the phoronix announcement (that makes me sick).

You might have misread the article and subsequent posts... plan was to release the WEC7 driver under the same X11 license used by the Linux version, and the MS-owned DDK bits under the same MS license *they* have today.

[plonoma]

Split KMS and GPU Drivers

Very good idea regarding the very positive consequences of this.

And DMA-BUF V4L2
Common Video Mode Data Structure / EDID Parser
What not a buffer mechanism generalized as much as possible? Not just for video but able to do video?
It's all just passing data in a fast and flexible way.
With a general data structure model to describe hierarchy in data structures.
(video: 2D pixels 3 or four n bit components per pixel, new stuff t times per second.)
(picture: 2D pixels(samples) 3 or four n bit components per pixel, new stuff event based.)
(music: 1D samples, new stuff t times per second.)
...