From: Daniel Thompson <daniel.thompson@linaro.org>
To: Doug Anderson <dianders@google.com>
Cc: Enric Balletbo Serra <eballetbo@gmail.com>,
Enric Balletbo i Serra <enric.balletbo@collabora.com>,
Jingoo Han <jingoohan1@gmail.com>,
Richard Purdie <rpurdie@rpsys.net>,
Jacek Anaszewski <jacek.anaszewski@gmail.com>,
Pavel Machek <pavel@ucw.cz>, Rob Herring <robh+dt@kernel.org>,
Brian Norris <briannorris@google.com>,
Guenter Roeck <groeck@google.com>,
Lee Jones <lee.jones@linaro.org>,
Alexandru Stan <amstan@google.com>,
linux-leds@vger.kernel.org,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye.
Date: Mon, 18 Dec 2017 20:21:55 +0000 [thread overview]
Message-ID: <20171218202155.wzefxazbjakd2dhh@oak.lan> (raw)
In-Reply-To: <CAD=FV=VEakDGqfEkOZbuiq=FvUw46=6u9rTOgTk5FyJ9_2Rh4A@mail.gmail.com>
On Mon, Dec 18, 2017 at 08:46:09AM -0800, Doug Anderson wrote:
> Hi,
>
> On Mon, Dec 18, 2017 at 5:31 AM, Daniel Thompson
> <daniel.thompson@linaro.org> wrote:
> > I think two different values on the userspace side should always map to
> > different values on the kernel side.
>
> This is what I thought originally, but I believe I've convinced myself
> that this contradicts other goals and therefore needs to be relaxed.
> Specifically:
>
> Goal #1: A linear adjustment in the number exposed to userspace should
> result in a linear increase in human perceived brightness.
>
> Goal #2: Don't needlessly throw away precision available to the
> hardware. For instance, if the hardware only supports 64, 128 or 256
> levels, it seems like a worthy goal to make sure that userspace can
> access each of these brightness levels.
>
>
> So if we accept that #1 and #2 are goals,
I'm not sure that I accept goal #1 for highly constrained hardware that
is physically capable only of a very few steps.
I think adopting Goal #1 favours the slider use-case too much over the
hot-key use case. If you linearise a tiny space then the hot-key risks
doing nothing then pressed.
It's not that I don't think this is a real problem but I think it is
one that must be solved in the ABI (e.g. by communicating the typical
curve to userspace and revealing true hardware steps).
> the only solution is to
> expose a larger "virtual" space and have more than one user-exposed
> value map to the same actual brightness. As a very simple example,
> let's say we have a backlight that allows 8 levels:
>
> 0 = black
> 1 = 20% user brightness
> 2 = 40% user brightness
> 3 = 60% user brightness
> 4 = 75% user brightness
> 5 = 85% user brightness
> 6 = 90% user brightness
> 7 = 95% user brightness
> 8 = 100% user brightness
Note that these patches are for the PWM backlight; these steps seem
unlikely even for an 8-bit PWM.
That leads us to a difficult question. When presented with a low-bit PWM
then are automatic curves the right tool? With such low steps we
probably need to compromise linearity to some extent (and maybe the DT
author may be forced to tune for slider versus hotkey depending on what
our form-factor is).
Daniel.
prev parent reply other threads:[~2017-12-18 20:22 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-16 14:11 [RFC v2 0/2] backlight: pwm_bl: support linear brightness " Enric Balletbo i Serra
2017-11-16 14:11 ` [RFC v2 1/2] backlight: pwm_bl: linear interpolation between values of brightness-levels Enric Balletbo i Serra
2017-11-20 18:58 ` Rob Herring
2017-11-27 11:21 ` Enric Balletbo Serra
2017-11-27 23:55 ` Doug Anderson
2017-11-27 23:52 ` Doug Anderson
2017-12-15 14:40 ` Daniel Thompson
2017-12-18 9:47 ` Enric Balletbo Serra
2017-12-18 13:15 ` Daniel Thompson
2017-11-16 14:11 ` [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye Enric Balletbo i Serra
2017-11-30 0:44 ` Doug Anderson
2017-11-30 11:27 ` Daniel Thompson
2017-11-30 16:57 ` Doug Anderson
2017-11-30 18:34 ` Enric Balletbo Serra
2017-11-30 19:06 ` Doug Anderson
2017-12-15 20:57 ` Pavel Machek
2017-12-18 10:40 ` Enric Balletbo Serra
2017-12-18 12:33 ` Pavel Machek
2017-12-18 13:53 ` Daniel Thompson
2017-12-15 14:51 ` Daniel Thompson
2017-12-18 10:27 ` Enric Balletbo Serra
2017-12-18 13:31 ` Daniel Thompson
2017-12-18 16:46 ` Doug Anderson
2017-12-18 20:21 ` Daniel Thompson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171218202155.wzefxazbjakd2dhh@oak.lan \
--to=daniel.thompson@linaro.org \
--cc=amstan@google.com \
--cc=briannorris@google.com \
--cc=devicetree@vger.kernel.org \
--cc=dianders@google.com \
--cc=eballetbo@gmail.com \
--cc=enric.balletbo@collabora.com \
--cc=groeck@google.com \
--cc=jacek.anaszewski@gmail.com \
--cc=jingoohan1@gmail.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=robh+dt@kernel.org \
--cc=rpurdie@rpsys.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®