Adding set_blob ioctl to DRM (original) (raw)

Rahul Sharma r.sh.open at gmail.com
Wed Feb 19 17:54:49 PST 2014


Thanks Dave,

On 20 February 2014 06:54, Dave Airlie <airlied at gmail.com> wrote:

I am working on enabling a Color Enhancement block for primary display for Exynos SoC. I need to set a bunch of parameters like Color Conversion matrix, Contrast Improvement parameters etc ~ 30 parameters from User Space.

I am planning to use KDS blob property to receive these parameters. Currently drivers are not allowed to create a blob property inside drm. Neither, user space can set the blob. There is no ioctl provided for same. I don't really like the idea of sticking unstructured data into an ioctl, for the driver to interpret, it opens the door to all kinds of ugly driver hacks, so I think we should have writable blobs, but with well defined structures inside them, not per-driver ones.

I agree with you. I will define these as generic structures which are complete sets of parameters, required by standard color algorithms. Something like this:

Color Reproduction: - R[r,g,b], G[r,g,b], B[r,g,b] - Cyan[r,g,b], Magenta[r,g,b], Yellow[r,g,b] - White[r,g,b] - Black[r,g,b]

I will share the code once it is in some shape.

Regards, Rahul Sharma.

Per-driver structures will lead to binary userspace drivers that start sticking a pll timings blob on the end and require it to set a mode, because I know driver developers will abuse any interface in the worst way possible.

Currently the only blob we really have is EDID and its well defined, so if we are going to add writable blobs, they need to be well defined and as little as possible driver specific, just to avoid driver writings doing what driver writers do. Dave.



More information about the dri-devel mailing list