linux-kernel - [RFC v2 0/2] backlight: pwm_bl: support linear brightness 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-next>] [day] [month] [year] [list]

Message-Id: <20171116141151.21171-1-enric.balletbo@collabora.com>
Date:   Thu, 16 Nov 2017 15:11:49 +0100
From:   Enric Balletbo i Serra <enric.balletbo@...labora.com>
To:     Daniel Thompson <daniel.thompson@...aro.org>
Cc:     Jingoo Han <jingoohan1@...il.com>,
        Richard Purdie <rpurdie@...ys.net>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>, Rob Herring <robh+dt@...nel.org>,
        Doug Anderson <dianders@...gle.com>,
        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, linux-kernel@...r.kernel.org
Subject: [RFC v2 0/2] backlight: pwm_bl: support linear brightness to human eye

Dear all,

This patch series is a second RFC to know your opinion about the way to
solve the problems exposed in the first RFC [1]

The first patch what tries to solve is the problem of granularity for high
resolution PWMs. The idea is simple interpolate between 2 brightness values
so we can have a high PWM duty cycle (a 16 bits PWM is up to 65535 possible
steps) without having to list out every possible value in the dts. I think
that this patch is required to not break backward compability, to be more
flexible and also extend the functionality to be able to use high resolution
PWM with enough steps to have a good UI experience in userspace.

The second patch is a bit more ambicious, the idea is let decide the driver
the brightness-levels required in function of the PWM resolution. To do this
we use a static table filled with the CIE 1931 algorithm values to convert
brightness to PWM duty cycle.

More detailed info is available in the commit message of every patch.

A couple of questions come to my mind:

- What's the amoung of steps we really need? Currently there is 1024 steps
  for a resolution of 16 bits, and 37 steps for a PWM with 8 bits of
  resolution. That seems to work well with both 16 bits and 8 bits. Tested
  on a Samsung Chromebook Plus (16 bits) and a SL50 device (8 bits)

- What about 32 bits or greather resolutions? We need to support it?
  I did a quick look and seems nobody requires it, but I don't really know.
  For now if we set more than 16 bits of resolution the driver triggers
  an error.

Waiting for your feedback.

Chances since v1:
- Add linear interpolation for high resolution PWM.
- Get rid of fixed point calculations and use a table instead.

[1] http://www.spinics.net/lists/devicetree/msg193262.html

Best regards,

Enric Balletbo i Serra (2):
  backlight: pwm_bl: linear interpolation between values of
    brightness-levels
  backlight: pwm_bl: compute brightness of LED linearly to human eye.

 .../bindings/leds/backlight/pwm-backlight.txt      |   2 +
 drivers/video/backlight/pwm_bl.c                   | 209 ++++++++++++++++++---
 include/linux/pwm_backlight.h                      |   3 +
 3 files changed, 191 insertions(+), 23 deletions(-)

-- 
2.9.3