Re: [PATCH 02/23] drm: Add structure for querying palette color capabilities

From: Daniel Vetter <daniel@ffwll.ch>
To: Matt Roper <matthew.d.roper@intel.com>
Cc: annie.j.matheson@intel.com, intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org, kausalmalladi@gmail.com,
	daniel.vetter@intel.com
Subject: Re: [PATCH 02/23] drm: Add structure for querying palette color capabilities
Date: Tue, 22 Sep 2015 15:02:40 +0200	[thread overview]
Message-ID: <20150922130240.GN3383@phenom.ffwll.local> (raw)
In-Reply-To: <20150916175131.GD28347@intel.com>

On Wed, Sep 16, 2015 at 10:51:31AM -0700, Matt Roper wrote:
> On Wed, Sep 16, 2015 at 11:06:59PM +0530, Shashank Sharma wrote:
> > From: Kausal Malladi <kausalmalladi@gmail.com>
> > 
> > The DRM color management framework is targeting various hardware
> > platforms and drivers. Different platforms can have different color
> > correction and enhancement capabilities.
> > 
> > A commom user space application can query these capabilities using the
> > DRM property interface. Each driver can fill this property with its
> > platform's palette color capabilities.
> > 
> > This patch adds new structure in DRM layer for querying palette color
> > capabilities. This structure will be used by all user space
> > agents to configure appropriate color configurations.
> > 
> > Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
> > Signed-off-by: Kausal Malladi <kausalmalladi@gmail.com>
> 
> I think you provided an explanation on a previous code review cycle, but
> I forget the details now...what's the benefit to using a blob for caps
> rather than having these be individual properties?  Individual
> properties seems more natural to me, but I think you had a justification
> for blobbing them together; that reasoning would be good to include in
> the commit message.

Yeah I'm leaning slightly towards individual props too, that would give us
a bit more freedom with placing them (e.g. if someone comes up with funky
hw where before_ctm and ctm are per-plane and after_ctm is on the crtc,
with only some planes support the before_ctm gamma table).

Also if you do per-prop properties instead of the blob you can drop the
version/reserved fields, since properties are inheritedly designed to be
extendible. So no need to revision them again (it only leads to more code
that might break).
-Daniel

> 
> 
> Matt
> 
> > ---
> >  include/uapi/drm/drm.h | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> > index 3801584..e3c642f 100644
> > --- a/include/uapi/drm/drm.h
> > +++ b/include/uapi/drm/drm.h
> > @@ -829,6 +829,17 @@ struct drm_event_vblank {
> >  	__u32 reserved;
> >  };
> >  
> > +struct drm_palette_caps {
> > +	/* Structure version. Should be 1 currently */
> > +	__u32 version;
> > +	/* For padding and future use */
> > +	__u32 reserved;
> > +	/* This may be 0 if not supported. e.g. plane palette or VLV pipe */
> > +	__u32 num_samples_before_ctm;
> > +	/* This will be non-zero for pipe. May be zero for planes on some HW */
> > +	__u32 num_samples_after_ctm;
> > +};
> > +
> >  /* typedef area */
> >  #ifndef __KERNEL__
> >  typedef struct drm_clip_rect drm_clip_rect_t;
> > -- 
> > 1.9.1
> > 
> 
> -- 
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx