Regards Shashank
On 9/21/2015 10:16 PM, Ville Syrjälä wrote: > On Wed, Sep 16, 2015 at 11:07:01PM +0530, Shashank Sharma wrote: >> From: Kausal Malladi <kausalmalladi at gmail.com> >> >> This patch adds new structures in DRM layer for Palette color >> correction.These structures will be used by user space agents >> to configure appropriate number of samples and Palette LUT for >> a platform. >> >> Signed-off-by: Shashank Sharma <shashank.sharma at intel.com> >> Signed-off-by: Kausal Malladi <kausalmalladi at gmail.com> >> --- >> include/uapi/drm/drm.h | 27 +++++++++++++++++++++++++++ >> 1 file changed, 27 insertions(+) >> >> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h >> index e3c642f..f72b916 100644 >> --- a/include/uapi/drm/drm.h >> +++ b/include/uapi/drm/drm.h >> @@ -840,6 +840,33 @@ struct drm_palette_caps { >> __u32 num_samples_after_ctm; >> }; >> >> +struct drm_r32g32b32 { >> + /* >> + * Data is in U8.24 fixed point format. >> + * All platforms support values within [0, 1.0] range, >> + * for Red, Green and Blue colors. >> + */ >> + __u32 r32; >> + __u32 g32; >> + __u32 b32; >> +}; >> + >> +struct drm_palette { >> + /* Structure version. Should be 1 currently */ >> + __u32 version; > > I don't think we want to version the blobs. For one, we don't have a way > for userspace to ask for a specific version, so the kernel wouldn't know > which version it should return to each client. > > If we ever need to come up with new version of a specific blob, I think we > just have to define another property for it. Either that or we'd some kind > of client cap stuff to negotiate the used version between the kernel and > a specific client. > > Well, I suppose we migth be able to borrow the "flags+extend at the end" > trick we sometimes use for ioctl parameters to work for blobs too. But I > have a feeling we don't want to go there. > > So yeah, I think we should go with the "blob layout is fixed for each > property" approach. Versioning then happens by introducing new versions > of the same property if needed. > Well, reason behind adding this version was, as this framework was a new development, we wanted to keep scope for further changes on request from other drivers/modules. But yes, I agree, its kind of overhead, so we can also remove it. Will do that in next patch set. >> + /* >> + * This has to be a supported value during get call. >> + * Feature will be disabled if this is 0 while set >> + */ >> + __u32 num_samples; >> + /* >> + * Starting of palette LUT in R32G32B32 format. >> + * Each of RGB value is in U8.24 fixed point format. >> + * Actual number of samples will depend upon num_samples >> + */ >> + struct drm_r32g32b32 lut[0]; >> +}; >> + >> /* typedef area */ >> #ifndef __KERNEL__ >> typedef struct drm_clip_rect drm_clip_rect_t; >> -- >> 1.9.1 >> >> _______________________________________________ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel >