[Intel-gfx] [PATCH 04/12] drm: Add structures for querying color capabilities

[Ville Syrjälä]

On Thu, Jul 02, 2015 at 05:45:32PM +0100, Damien Lespiau wrote:
> On Thu, Jul 02, 2015 at 05:20:45PM +0100, Damien Lespiau wrote:
> > On Wed, Jul 01, 2015 at 09:18:14PM +0530, Kausal Malladi wrote:
> > > From: Kausal Malladi <Kausal.Malladi at intel.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 color capabilities.
> > > 
> > > This patch adds new structures in DRM layer for querying color
> > > capabilities. These structures will be used by all user space
> > > agents to configure appropriate color configurations.
> > 
> > As I indicated before, I don't think we should go for a full fledged 
> > query API, because, I don't believe we can ever make it good enough to 
> > cover future hardware (and probably not today's hardware across 
> > vendors). 
> >  
> > These kinds of query APIs have been frown upon in the past for that 
> > exact reason. 
> >  
> > - Accept configurations that are mostly likely to be working across vendors 
> > (256 enties for 8 bits) That should be enough for basic functionality. 
> >  
> > - To support things that are really hw specific: make sure the kernel API can 
> > accept those, put the hw specific knowledge into a user-space HAL where APIs 
> > can evolve. What you're trying to do here with queries about per-platform 
> > details can go into userspace and still have a generic compositor code using 
> > those limits. Let's just not put the limits into the kernel API, we won't be 
> > able to get it right. 
> >  
> > Now maybe there's a middle ground and we can expose basic limits. In this case, 
> > maybe a list of supported LUT sizes, but the sampling details don't belong to a 
> > kernel interface IMHO. I'm even hesitant putting the hw precision at that 
> > level. 
> 
> To re-iterate the point with actual examples, the proposed query API
> doesn't seem to handle things we'd want to know today:
> 
> - What are the extra values are coding for. eg. for 8 bits, the values
>   after index 255 are special and we have no description for those. (and
>   it can get fiddly to describe them, you may want to add the type of
>   interpolation for instance).
> - How to you represent capabilities across hardware unit. Eg. split
>   gamma lowering the number of LUT entries.
> 
> That somewhat demonstrates my point I think. We won't be able to get the
> query API right.

Yeah. My first idea for the gamma stuff was that we'd simply have the
blob property for the data, and then a separate enum property which
decides how we interpret the blob contents. The default for the enum
would be the 8bpc/256 entries thing always, but the other values could
be potentially hardware specific. Obviously this would limit the use of
the fancier modes to the atomic API since you'd need to configure both
the blob and enum at the same time. But I don't see why we shouldn't
be allowed to rely on atomic from now on.

Well, I guess we could allow the user to change just the enum if the
expected blob size will match what was already provided, although
thinking up a valid use case for this is a bit hard :)

-- 
Ville Syrjälä
Intel OTC