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@xxxxxxxxx>
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@xxxxxxxxx>
Signed-off-by: Kausal Malladi <kausalmalladi@xxxxxxxxx>
---
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@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
