Re: [PATCH v3 3/3] backlight: pwm_bl: Fix interpolation

From
Alexandru M Stan <hidden>
Date
2020-11-02 18:53:30
Also in
dri-devel, linux-pwm, lkml
Reply to
Daniel Thompson, 2020-10-29
On Wed, Oct 28, 2020 at 8:12 AM Daniel Thompson
[off-list ref] wrote:
On Wed, Oct 21, 2020 at 10:04:45PM -0700, Alexandru Stan wrote:
quoted
The previous behavior was a little unexpected, its properties/problems:
1. It was designed to generate strictly increasing values (no repeats)
2. It had quantization errors when calculating step size. Resulting in
unexpected jumps near the end of some segments.

Example settings:
      brightness-levels = <0 1 2 4 8 16 32 64 128 256>;
      num-interpolated-steps = <16>;

Whenever num-interpolated-steps was larger than the distance
between 2 consecutive brightness levels the table would get really
discontinuous. The slope of the interpolation would stick with
integers only and if it was 0 the whole line segment would get skipped.

The distances between 1 2 4 and 8 would be 1 (property #1 fighting us),
and only starting with 16 it would start to interpolate properly.

Property #1 is not enough. The goal here is more than just monotonically
increasing. We should still care about the shape of the curve. Repeated
points might be desired if we're in the part of the curve where we want
to go slow (aka slope near 0).

Problem #2 is plainly a bug. Imagine if the 64 entry was 63 instead,
the calculated slope on the 32-63 segment will be almost half as it
should be.

The most expected and simplest algorithm for interpolation is linear
interpolation, which would handle both problems.
Let's just implement that!

Take pairs of points from the brightness-levels array and linearly
interpolate between them. On the X axis (what userspace sees) we'll
now have equally sized intervals (num-interpolated-steps sized,
as opposed to before where we were at the mercy of quantization).

END
INTERESTING.

I guess this a copy 'n paste error from some internal log book?
Better removed... but I won't lose sleep over it.
Sorry! Yeah, I mistakenly duplicated the "END" line in patman.
quoted
Signed-off-by: Alexandru Stan <redacted>
I've waited a bit to see how strong the feelings were w.r.t. getting rid
of the division from the table initialization. It was something I was
aware of during an earlier review but it was below my personal nitpicking
threshold (which could be badly calibrated... hence waiting). However
it's all been quiet so:

Reviewed-by: Daniel Thompson <redacted>


Daniel.

Alexandru Stan (amstan)
Thread (6 messages) 6 messages, 4 authors, last reply 2020-11-04
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help