On Tuesday 21 December 2010 18:29:56 Matt Sealey wrote:
The only thing that is currently being enforced is that no interfaces enter the mainline kernel that rely on closed source user space. Once something is merged in mainline, you are generally free to write code under any license you want against that interface.
Yes, this is basically it: the problem here is that Alan is stipulating that as a copyright holder in the kernel he has a big problem with merging the code, but in fact as the merge proposal only includes GPL code, nobody has a leg to stand on except on moral grounds, and policy grounds. There is no legal issue here. It is not going into mainline, fair enough. What I am curious about is why did Linaro push it to dri-devel in the first place? I think the concept of taking a driver from a BSP and then just FLINGING it at mainline is not responsible in the first place. Isn't it enough to go into the Linaro tree, discretely and quietly? Then we can have a discussion about what to do about it within Linaro.
That's not how Linaro works. I forwarded it to the DRI list to get technical input on what would be needed to have it merged in mainline. If things were looking better on this front, we could get it on track for mainline merging, and backport it into the Linaro tree as soon as it hits linux-next. This is obviously not going to happen unless we can find at least a subset of the code without legal problems that we can clean up enough for integration.
Frankly, this discussion (besides the sidetrack to the non-existant legal issues) did pop up a major problem in the possibility of unifying the IPU, dual GPU and other graphics subsystem frameworks on the i.MX processor line, and potentially others too (TI's LCDC and PVR graphics) in that DRM/DRI security policy will forbid them (in the form of David Arlie complaining) from sharing the same memory area, MMUs on or off. This actually means all 2D, 2D acceleration, 3D acceleration and DMA between the units requires bounce buffers and some overly complicated memory copying between memory areas for them to interoperate. I think TI hit this problem trying to get a texture from the DSP to the GPU to render it to a texture and came up with an awful (closed source :) method of ioctls and so on to achieve it. I had an idea to solve it using DRM and GEM but it's been shot down in concept now... what's the point? It'll never get into mainline.
Don't give up so early, there are a number of separate problems to solve here. As far as I understand, the desire among many people is to have the 3D acceleration hidden. Fine, so we can still do accelerated 2D with free drivers and shouldn't be bothered by the fact that we don't get 3D. There is a lot of work to do on proper 2D drivers and getting them into mainline still, so let's focus on that and do a proper implementation for as many chips as possible.
By the time that is done, we may well have one or more manufacturers willing to work with us on 3D support as well.
Arnd