linux-kernel - Re: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye.

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: <20171218135324.ulvacip55md4g73n@oak.lan>
Date:   Mon, 18 Dec 2017 13:53:24 +0000
From:   Daniel Thompson <daniel.thompson@...aro.org>
To:     Enric Balletbo Serra <eballetbo@...il.com>
Cc:     Pavel Machek <pavel@....cz>, Doug Anderson <dianders@...gle.com>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        Jingoo Han <jingoohan1@...il.com>,
        Richard Purdie <rpurdie@...ys.net>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Brian Norris <briannorris@...gle.com>,
        Guenter Roeck <groeck@...gle.com>,
        Lee Jones <lee.jones@...aro.org>,
        Alexandru Stan <amstan@...gle.com>, linux-leds@...r.kernel.org,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED
 linearly to human eye.

On Mon, Dec 18, 2017 at 11:40:59AM +0100, Enric Balletbo Serra wrote:
> Hi Pavel,
> 
> 2017-12-15 21:57 GMT+01:00 Pavel Machek <pavel@....cz>:
> > Hi!
> >
> >> Yes, I think that how you describe luminance and lightness is right,
> >> and sounds good improve the doc.
> >>
> >> To be clear the correction table for PWM values can be calculated with
> >> this code.
> >>
> >> OUTPUT_SIZE = 65535      # Output integer size
> >> INPUT_SIZE = 2047
> >>
> >> def cie1931(L):
> >>     L = L*100.0
> >>     if L <= 8:
> >>         return (L/902.3)
> >>     else:
> >>         return ((L+16.0)/116.0)**3
> >>
> >> x = range(0,int(INPUT_SIZE+1))
> >> y = [int(round(cie1931(float(L)/INPUT_SIZE)*(OUTPUT_SIZE))) for L in x]
> >
> > Can we just generate the table on the fly? Should not be hard to do in
> > fixed point, right?
> 
> This was discussed a bit in previous RFC which had the code to
> generate the table on the fly, see [1]. The use of a fixed table or an
> on the fly table is something that I'll let the maintainers to decide.
> I've no strong opinion on use the on the fly table if someone takes
> care to review deeply the fixed point maths :)

The last time we discussed this we concluded we would introduce linear
interpolation to make it easier enlarge the small tables we typically 
see in devicetree.

Having done that it seemed attractive (at least to me) to reuse any
interpolation code we get and then simply provide a "sane" default look 
up table for use by DT authors who don't really know how to map PWM on/
off times to luminance.

I did review the original fixed point code for the first RFC. IIRC some 
of the low level functions *looked* they could overflow but, on closer 
inspection, were never actually overflowed in practice due to the 
number ranges used by the callers. To be honest part of the attraction
of a LUT instead was that I wouldn't have to closely review nor ensure
all the fixed point code was properly commented ;-) .

The other item in favour of LUT was that (as Doug A. pointed out) PWM 
duty-cycle to luminance is not strictly linear. Whilst at the moment I 
am OK to discount this effect it is possible we might want to combined
the luminance to human perception values with values read out from
graphs in a datasheet.

Enric: Having said all that I don't want to give you a really heavy
       handed steer here. If you think the code was cleaner or clearer
       when using the formulae then I'd be happy to review the fixed
       point code.

Daniel.