Re: [PATCH v3 2/4] backlight: Expose brightness curve type through sysfs

On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote:

Hello Matthias,

On Fri, Aug 16, 2019 at 02:10:51PM -0700, Matthias Kaehlcke wrote:

quoted

On Fri, Aug 16, 2019 at 09:47:54PM +0200, Uwe Kleine-König wrote:

quoted

On Fri, Aug 16, 2019 at 10:51:57AM -0700, Matthias Kaehlcke wrote:

quoted

Hi Uwe,

On Fri, Aug 16, 2019 at 06:51:48PM +0200, Uwe Kleine-König 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>

I wonder what kind of problem you are solving here. Can you describe
that in a few words?

The human eye perceives brightness in a logarithmic manner. For
backlights with a linear brightness curve brightness controls like
sliders need to use a mapping to achieve a behavior that is perceived
as linear-ish (more details: http://www.pathwaylighting.com/products/downloads/brochure/technical_materials_1466797044_Linear+vs+Logarithmic+Dimming+White+Paper.pdf)

As of now userspace doesn't have information about the type of the
brightness curve, and often uses heuristics to make a guess, which may
be right most of the time, but not always. The new attribute eliminates
the need to guess.

This is about backlights right? So the kernel provides to userspace an
interval [0, x] for some x and depending on the physics of the the
backlight configuring x/2 (probably?) either means 50% measured light or
50% perceived light, right?

correct

quoted

I wonder if it would be possible instead of giving different backlight
implementations the freedom to use either linear or logarithmic (or
quadratic?) scaling and tell userspace which of the options were picked
require the drivers to provide a (say) linear scaling and then userspace
wouldn't need to care about the exact physics.

In an ideal world the backlight interface would be consistent as you
suggest, however there are plenty of existing devices which use the
'other' scaling (regardless of which is chosen as the 'correct'
one). Userspace still has to deal with these. And changing previously
'logarithmic' drivers to linear (or viceversa) may 'break' userspace,
when it keeps using its 'old' scaling, which now isn't correct anymore.

It might be subjective, or maybe I'm just too optimistic, but I think if
there was no policy before about the meaning of

	echo 17 > brightness

other than "brighter than lower values and darker than higher ones"
introducing (say) the scale is intended to represent a linear brightness
curve is ok.

Unless userspace jumps through hoops and tries to identify the actual
device it is running on it is wrong on some machines anyhow and we're
only shifting the set of affected machines with a tighter policy (until
that userspace application is fixed).

I believe that there are two common approaches by userspace at present:

1. Assume the scale is perceptual and we can directly map a slider
   to the backlight value. This is common simply because most ACPI
   backlights are perceptual and therefore when tested in a laptop
   it works OK.

2. Assume that is max brightness is small (e.g. ACPI) then the
   scale is perceptual and if the max brightness is large (e.g.
   a PWM) then the scale is linear and apply a correction
   function between the slider and the control.

That historic baggage makes is diffcult to "just define a standardized
scale"... especially given that if we selected a standardized scale we
would probably want a perceptual scale with lots of steps (e.g. break
the heuristic).

And the big upside is that in the end (i.e. when all kernel drivers and
userspace applications are adapted to provide/consume the "correct"
curve) the result is simpler.

My view is that this convergence will eventually be achieved but it will
happen through the obsolescence of the backlight sysfs interface. The
sysfs interface has other flaws, in particular no integration with the
DRM connector API.

Thus I would expect an alternative interface to emerge, most likely as
part of the DRM connector API. I'd expect such a new API to a
perceptual scale and to have a fixed max brightness with enough
steps to support animated backlight effects (IIRC 0..100 has been
proposed in the past) 

In the mean time getting the existing collection of backlight drivers
marked up as linear/logarithmic/etc will ease the introduction of that
API because, within the kernel, we might have gathered enough knowledge
to have some hope of correctly mapping each backlight onto a
standardized scale.


Daniel.