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?