linux-kernel - Re: [PATCH v2] drm/color: Document CTM eqations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170217151656.GV31595@intel.com>
Date:   Fri, 17 Feb 2017 17:16:56 +0200
From:   Ville Syrjälä <ville.syrjala@...ux.intel.com>
To:     Lionel Landwerlin <lionel.g.landwerlin@...el.com>
Cc:     Brian Starkey <brian.starkey@....com>,
        Daniel Stone <daniel@...ishbar.org>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Jani Nikula <jani.nikula@...ux.intel.com>,
        Sean Paul <seanpaul@...omium.org>
Subject: Re: [PATCH v2] drm/color: Document CTM eqations

On Fri, Feb 17, 2017 at 03:05:28PM +0000, Lionel Landwerlin wrote:
> 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@...ux.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@...ux.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.

Which is what I thought we had already agreed to do when we started
planning this color management stuff. But I guess that plan got
somehow scrapped after I was no longer part of the discussions.

> It seems some people have concerned about HDR.

HDR is definitely something I'd like to have a look at.

-- 
Ville Syrjälä
Intel OTC