abuse of dumb ioctls in exynos

Patrik Jakobsson patrik.r.jakobsson at gmail.com
Tue Apr 30 13:13:54 PDT 2013


On Mon, Apr 29, 2013 at 12:31 PM, Dave Airlie <airlied at 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


More information about the dri-devel mailing list