On Mon, Apr 29, 2013 at 12:31 PM, Dave Airlie airlied@gmail.com wrote:
The reason we (currently) use the dumb buffer interface is because it does pretty much exactly what we need it to, as we only want linear RGB buffers:
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.
We could have a "less dumb" interface with support for common stuff like scanout bufs, offscreen bufs, cursor bufs, CMA, overlays, etc, and with room for driver specific flags. There could also be a generic interface for 2d acceleration (solid and copy) and the sync stuff needed for it. For stuff that doesn't fit our interface there is always the possibility to add ioctls. I think the abuse of the dumb buffer interface is an indication that there is a need for something like this.
-Patrik