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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
