Adding set_blob ioctl to DRM

[Rahul Sharma]

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.