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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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@xxxxxx>:
> > 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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux