[Intel-gfx] [PATCH 04/12] drm: Add structures for querying color capabilities
Damien Lespiau
damien.lespiau at intel.com
Fri Jul 3 03:28:41 PDT 2015
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
More information about the Intel-gfx
mailing list