On Mon, Aug 19, 2019 at 11:50:49AM -0700, Matthias Kaehlcke wrote:

Hi Daniel,

On Mon, Aug 19, 2019 at 11:02:41AM +0100, Daniel Thompson wrote:

quoted

On Fri, Aug 16, 2019 at 10:53:17AM -0700, Matthias Kaehlcke wrote:

quoted

On Fri, Aug 16, 2019 at 04:54:18PM +0100, Daniel Thompson wrote:

quoted

On 07/08/2019 21:15, Matthias Kaehlcke wrote:

quoted

On Tue, Jul 09, 2019 at 12:00:05PM -0700, Matthias Kaehlcke wrote:

quoted

Backlight brightness curves can have different shapes. The two main
types are linear and non-linear curves. The human eye doesn't
perceive linearly increasing/decreasing brightness as linear (see
also 88ba95bedb79 "backlight: pwm_bl: Compute brightness of LED
linearly to human eye"), hence many backlights use non-linear (often
logarithmic) brightness curves. The type of curve currently is opaque
to userspace, so userspace often uses more or less reliable heuristics
(like the number of brightness levels) to decide whether to treat a
backlight device as linear or non-linear.

Export the type of the brightness curve via the new sysfs attribute
'scale'. The value of the attribute can be 'linear', 'non-linear' or
'unknown'. For devices that don't provide information about the scale
of their brightness curve the value of the 'scale' attribute is 'unknown'.

Signed-off-by: Matthias Kaehlcke <mka@chromium.org>

Daniel (et al): do you have any more comments on this patch/series or
is it ready to land?

I decided to leave it for a long while for others to review since I'm still
a tiny bit uneasy about the linear/non-linear terminology.

However that's my only concern, its fairly minor and I've dragged by feet
for more then long enough, so:
Reviewed-by: Daniel Thompson <redacted>

Thanks!

If you or someone else has another suggestion for the terminology that
we can all agree on I'm happy to change it.

As you will see in my reply to Uwe. The term I tend to adopt when I want
to be precise about userspace behaviour is "perceptual" (e.g. that a
backlight can be mapped directly to a slider and it will feel right).

However that raises its own concerns: mostly about what is perceptual
enough.

Clear the automatic brightness curve support in the PWM driver is
perceptual.

To be honest I suspect that in most cases a true logarithmic curve (given a
sane exponent) would be perceptual enough. In other words it will feel
comfortable with a direct mapped slider and using it for animation
won't be too bad.

However when we get right down to it *that* is the information that is
actually most useful to userspace: explicit confirmation that the scale
can be mapped directly to a slider. I think it also aligned better with
Uwe's feedback (e.g. to start working towards having a preferred scale).

IIUC the conclusion is that there is no need for a string attribute
because we only need to distinguish between 'perceptual' and
'non-perceptual'. If that is correct, do you have any preference for
the attribute name ('perceptual_scale', 'perceptual', ...)?

More a summary than a conclusion! There is a reason I have left a bit or
space for others to comment on this over the last month (and a bit).

To be clear my Reviewed-by: means that I believe that the kernel is better
with "non-linear/linear/unknown" than without it and that I am comfortable
the API isn't likely to be a millstone for us.

Lee, Jingoo: Either of you care to offer $0.02


Daniel.