Re: [PATCH 04/12] drm: Add structures for querying color capabilities

Damien Lespiau
2015-07-03T10:28:41Z

On Fri, Jul 03, 2015 at 08:41:31AM +0200, Daniel Vetter wrote:
> > 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.
>
> Yeah, enum+blob is what I like too. We can do one gamma table format enum
> in drm core. And drivers can then create it with just the enum values they
> actually support, similar to how we have rotation/mirror defines for
> everything, but the driver doesn't necessarily support it all. And the
> enum would fully encode everything there is to know about a layout, i.e.
> including excat precision and stuff like the 1025th/513th additional entry
> we have in some intel gamma tables.

I'm assuming you're still talking about 3 separate properties though?
pre-csc lut, csc, post-csc lut?

--
Damien