linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@google.com>
To: Enric Balletbo Serra <eballetbo@gmail.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>,
	Jingoo Han <jingoohan1@gmail.com>,
	Enric Balletbo i Serra <enric.balletbo@collabora.com>,
	Lee Jones <lee.jones@linaro.org>,
	Richard Purdie <rpurdie@rpsys.net>,
	Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	Pavel Machek <pavel@ucw.cz>, Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Brian Norris <briannorris@google.com>,
	Guenter Roeck <groeck@google.com>,
	linux-leds@vger.kernel.org,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Alexandru M Stan <amstan@chromium.org>
Subject: Re: [RFC 0/2] backlight: pwm_bl: support linear brightness to human eye
Date: Thu, 14 Sep 2017 09:01:33 -0700	[thread overview]
Message-ID: <CAD=FV=VnrEdbh35TTSOc8-SuicENutXKPBdENumrKZEMLRSRyA@mail.gmail.com> (raw)
In-Reply-To: <CAFqH_53hL_UCVQg2p8sdsGaoyWOou9a3Kd5H7MVMVLumH5_cAg@mail.gmail.com>

Hi,

On Thu, Sep 14, 2017 at 3:46 AM, Enric Balletbo Serra
<eballetbo@gmail.com> wrote:
> Based on this seems reasonable maintain current implementation to not
> break backward compability. Even, I think makes sense improve current
> implementation by adding somekind of piecewise linear concept to the
> brightness levels, similar to Doug's suggestion. So if we want, i.e,
> 256 levels or more, instead of specify the full table in the DT we can
> only specify some points in DT but the driver can expose to userspace
> more steps (how many?) between two brightness levels.

It seems sane to me.  Personally I'd say that if you're using
piecewise linear you just pick a number of levels to expose, perhaps
16383, or 32767, or 65535) and expose that many levels for everyone.
It's possible that bumping the brightness up by "1" will not actually
change a hardware register, but that seems like it would be fine,
right?

Probably you'd want to require some sort of dt change to enable
piecewise linear since it seems plausible that you could break
existing boards if you started interpolating.

> Of course, this
> doesn't makes the live of the future users easier but I think will
> make the live of the current users of this interface more flexible
> (specially when you want lots of levels)
>
> Then, to make the user live easier, there is the thing about human
> perception, we can move brightness-levels to be optional and fall to
> apply the human perception code if it's not specified. Here the thing
> and point of discussion is, if the cie1931 is the right algorithm to
> do the 'magic' in the driver. From what I investigated seems that is
> but I might be wrong.

I don't personally know, so hopefully someone else can comment.


-Doug

  reply	other threads:[~2017-09-14 16:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-04 15:35 [RFC 0/2] backlight: pwm_bl: support linear brightness to human eye Enric Balletbo i Serra
2017-09-04 15:35 ` [RFC 1/2] dt-bindings: pwm-backlight: add brightness-levels-scale property Enric Balletbo i Serra
2017-09-05 11:07   ` Daniel Thompson
2017-09-05 13:45   ` Guenter Roeck
2017-09-04 15:35 ` [RFC 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye Enric Balletbo i Serra
2017-09-05 11:05 ` [RFC 0/2] backlight: pwm_bl: support linear brightness " Daniel Thompson
2017-09-05 11:09   ` Daniel Thompson
2017-09-05 16:34   ` Jingoo Han
2017-09-07 18:04     ` Doug Anderson
2017-09-08 11:18       ` Daniel Thompson
2017-09-08 17:39         ` Doug Anderson
2017-09-14 10:46           ` Enric Balletbo Serra
2017-09-14 16:01             ` Doug Anderson [this message]
2017-09-18 16:00             ` Daniel Thompson
2017-09-19 22:27               ` Enric Balletbo Serra

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='CAD=FV=VnrEdbh35TTSOc8-SuicENutXKPBdENumrKZEMLRSRyA@mail.gmail.com' \
    --to=dianders@google.com \
    --cc=amstan@chromium.org \
    --cc=briannorris@google.com \
    --cc=daniel.thompson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --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=mark.rutland@arm.com \
    --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;
as well as URLs for NNTP newsgroup(s).