[Intel-gfx] [RFC v1 1/7] drm/i915: Add gamma mode property

[Brian Starkey]

Hi,

On Fri, Mar 22, 2019 at 01:06:01PM +0000, Shankar, Uma wrote:
> 
> 
> >-----Original Message-----
> >From: Roper, Matthew D
> >Sent: Friday, March 22, 2019 2:50 AM
> >To: Shankar, Uma <uma.shankar at intel.com>
> >Cc: intel-gfx at lists.freedesktop.org; Lankhorst, Maarten
> ><maarten.lankhorst at intel.com>; Syrjala, Ville <ville.syrjala at intel.com>; Sharma,
> >Shashank <shashank.sharma at intel.com>
> >Subject: Re: [RFC v1 1/7] drm/i915: Add gamma mode property
> >
> >On Tue, Mar 19, 2019 at 02:00:12PM +0530, Uma Shankar wrote:
> >> Gen platforms support multiple gamma modes, currently it's hard coded
> >> to operate only in 1 specific mode.
> >> This patch adds a property to make gamma mode programmable.
> >> User can select which mode should be used for a particular usecase or
> >> scenario.
> >>
> >> Signed-off-by: Uma Shankar <uma.shankar at intel.com>
> >
> >I haven't reviewed the series in depth, but I'm a bit confused on how userspace would
> >approach using this property.  This seems to be exposing hardware implementation
> >details that I wouldn't expect userspace to need to worry about (plus I don't think any
> >of the property values here convey any specific meaning to someone who hasn't read
> >the Intel bspec/PRM).  E.g., why does userspace care about "split gamma" when the
> >driver takes care of the programming details and userspace never sees the actual way
> >the registers are laid out and written?
> >My understanding is that what really matters is how many table entries there are for
> >userspace to fill in, what input range(s) they cover, and how the bits of each table
> >entry are interpreted.  I think we'd want to handle this in a vendor-agnostic way in the
> >DRM core if possible; most of the display servers that get used these days are cross-
> >platform and probably won't want to add Intel-specific logic (or platform-specific
> >logic if we wind up with a different set of options on future Intel platforms).
> 
> Ok, will try to re-structure this to make it vendor agnostic way. Also will add enough
> documentation for the usage of the property. 
> 
> @Ville- What do you recommend or suggest for these interfaces.

Just to add to the conversation - some of our HW has fixed LUTs, which
isn't really very well exposed by the current UAPI. We do it by having
the kernel driver just look at the userspace-provided blob, and it if
matches the fixed curve we accept it.

I thought one way to expose this would be to have kernel-created blobs
representing the fixed LUTs, which userspace could query to figure out
what LUTs were available.

That might not need to interact with the proposals here, but perhaps
if there's going to be some kind kind of gamma-mode enumeration, fixed
LUTs could be considered there, too.

Cheers,
-Brian