On Mon, Apr 29, 2013 at 12:31 PM, Dave Airlie <airlied@xxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
