>> Except in the cases where it doesn't do what you want, and possibly in >> the future where it does less of what you want. You've started on a >> slippery slope, and I'm stopping you before you make things worse. >> >> You are going to have to get SoC kernel drivers to add an ioctl that >> you can use, if you insist on trying to mangle all the different code >> paths into a single userspace driver, then you are going to take a lot >> of pain. Its the old helper library vs midlayer, you are inventing a >> DDX midlayer when you should be inventing a DDX helper library. > > No argue there, but it would make sense to have a common set of ioctls for > buffer management. The dumb buffer interface is for generic userspace but for > non-generic cases there is still a need for something to prevent code > duplication for the SoC people. No it means SoC people need to duplicate more code in userspace. Adding restrictive interfaces to do dumb buffer allocation is never going to end well, someone will always come up with a new buffer type that is slightly different than the previous ones you came up with for their special SoC. The old TTM APIs we had tried to do this generically, and it was too messy. I'm not sure if I can say this plainer: THIS IS NOT A GOOD IDEA AND I WON'T MERGE IT. You also defeated any hope of me taking you seriously when you suggested adding generic accel interfaces for 2D, because acceleration doesn't belong in the kernel, Lets get this straight, drm isn't fbdev, it isn't an unmaintained free for all fastest hack wins. If I catch this sort of bullshit happening in drm drivers I'll be pulling maintainer plugs out. Dave. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
