Thanks Dave,
On 20 February 2014 06:54, Dave Airlie <airlied@xxxxxxxxx> 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.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
