[PATCH v2] drm/color: Document CTM eqations

[Lionel Landwerlin]

On 17/02/17 14:56, Ville Syrjälä wrote:
> On Fri, Feb 17, 2017 at 02:42:26PM +0000, Lionel Landwerlin wrote:
>> On 17/02/17 13:54, Brian Starkey wrote:
>>> What's the verdict? We've got [1] which is about to become another
>>> (driver) implementation - better to change before that merges than
>>> after I guess.
>>>
>>> -Brian
>>>
>>> [1] https://lkml.org/lkml/2017/2/13/304
>>>
>>> On Wed, Feb 15, 2017 at 11:56:55AM +0000, Daniel Stone wrote:
>>>> Hi,
>>>>
>>>> On 15 February 2017 at 11:39, Ville Syrjälä
>>>> <ville.syrjala at linux.intel.com> wrote:
>>>>> On Tue, Jan 31, 2017 at 06:46:39PM +0100, Daniel Vetter wrote:
>>>>>> On Tue, Jan 31, 2017 at 6:22 PM, Ville Syrjälä
>>>>>> <ville.syrjala at linux.intel.com> wrote:
>>>>>>> Hmm. Two's complement is what I was thinking it is. Which shows that
>>>>>>> I never managed to read the code in any detail. Definitely needs to
>>>>>>> be documented properly.
>>>>>> That sounds supremely backwards. I guess we can't fix this anymore?
>>>>> I have no idea. Anyone else?
>>>> I don't know of any implementation using this; maybe closed Intel
>>>> Android stuff? Certainly GitHub showed no-one using it, and neither X
>>>> nor Weston/Mutter are using it yet.
>>>>
>>>> Cheers,
>>>> Daniel
>> If we're talking fixed point reprsentation, ChromeOS is using this :
>>
>> https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?q=DrmDevice&l=209
> So it's already using the sign+magnitude stuff. Which presumably
> means we can't change it to two's complement anymore :( Maybe we add a
> CTM2 property ;)
>
> Using sign+magnitude definitely looks rather inefficient since there's
> a branch inside the loop. With two's complement you wouldn't need that
> thing slowing you down.
>
If you're seriously considering that, you might also want to bump struct 
drm_color_lut to use 32bits fields.
It seems some people have concerned about HDR.