I was trying to adjust the brightness for a new chromebook:
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2291209
Like a lot of panels, the low end needs to be cropped,
and now that we have the interpolation stuff I wanted to make use of it
and bake in even the curve.
I found the behavior a little unintuitive and non-linear. See patch 1
for a suggested fix for this.
Unfortunatelly a few veyron dts files were relying on this
(perhaps weird) behavior. Those devices also want a minimum brightness.
The issue is that they also want the 0% point for turning off the
display.
https://github.com/torvalds/linux/commit/6233269bce47bd450196a671ab28eb1ec5eb88d9#diff-e401ae20091bbfb311a062c464f4f47fL23
So the idea here is to change those dts files to only say <3 255> (patch
3), and add in a virtual 0% point at the bottom of the scale (patch 2).
We have to do this conditionally because it seems some devices like to
have the scale inverted:
% git grep "brightness-levels\s*=\s*<\s*[1-9]"|cat
arch/arm/boot/dts/tegra124-apalis-eval.dts: brightness-levels = <255 231 223 207 191 159 127 0>;
Alexandru Stan (3):
backlight: pwm_bl: Fix interpolation
backlight: pwm_bl: Artificially add 0% during interpolation
ARM: dts: rockchip: Remove 0 point in backlight
arch/arm/boot/dts/rk3288-veyron-jaq.dts | 2 +-
arch/arm/boot/dts/rk3288-veyron-minnie.dts | 2 +-
arch/arm/boot/dts/rk3288-veyron-tiger.dts | 2 +-
drivers/video/backlight/pwm_bl.c | 78 +++++++++++-----------
4 files changed, 42 insertions(+), 42 deletions(-)
--
2.27.0
After the "PWM backlight interpolation adjustments" patches, the
backlight interpolation works a little differently. The way these
dts files were working before was relying on a bug (IMHO).
Remove the 0-3 range since otherwise we would have a 252 long
interpolation that would slowly go between 0 and 3, looking really bad
in userspace.
We'll still have the 0% point available to userspace, "backlight:
pwm_bl: Artificially add 0% during interpolation" takes care of that.
Signed-off-by: Alexandru Stan <[email protected]>
---
arch/arm/boot/dts/rk3288-veyron-jaq.dts | 2 +-
arch/arm/boot/dts/rk3288-veyron-minnie.dts | 2 +-
arch/arm/boot/dts/rk3288-veyron-tiger.dts | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
index 171ba6185b6d..af4b21636c08 100644
--- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
@@ -20,7 +20,7 @@ / {
&backlight {
/* Jaq panel PWM must be >= 3%, so start non-zero brightness at 8 */
- brightness-levels = <0 8 255>;
+ brightness-levels = <8 255>;
num-interpolated-steps = <247>;
};
diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
index 383fad1a88a1..b25aa2f3cbee 100644
--- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
@@ -39,7 +39,7 @@ volum_up {
&backlight {
/* Minnie panel PWM must be >= 1%, so start non-zero brightness at 3 */
- brightness-levels = <0 3 255>;
+ brightness-levels = <3 255>;
num-interpolated-steps = <252>;
};
diff --git a/arch/arm/boot/dts/rk3288-veyron-tiger.dts b/arch/arm/boot/dts/rk3288-veyron-tiger.dts
index 069f0c2c1fdf..52a84cbe7a90 100644
--- a/arch/arm/boot/dts/rk3288-veyron-tiger.dts
+++ b/arch/arm/boot/dts/rk3288-veyron-tiger.dts
@@ -23,7 +23,7 @@ / {
&backlight {
/* Tiger panel PWM must be >= 1%, so start non-zero brightness at 3 */
- brightness-levels = <0 3 255>;
+ brightness-levels = <3 255>;
num-interpolated-steps = <252>;
};
--
2.27.0
On Mon, Jul 20, 2020 at 9:27 PM Alexandru Stan <[email protected]> wrote:
>
> I was trying to adjust the brightness for a new chromebook:
> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/2291209
> Like a lot of panels, the low end needs to be cropped,
> and now that we have the interpolation stuff I wanted to make use of it
> and bake in even the curve.
>
> I found the behavior a little unintuitive and non-linear. See patch 1
> for a suggested fix for this.
>
> Unfortunatelly a few veyron dts files were relying on this
> (perhaps weird) behavior. Those devices also want a minimum brightness.
> The issue is that they also want the 0% point for turning off the
> display.
> https://github.com/torvalds/linux/commit/6233269bce47bd450196a671ab28eb1ec5eb88d9#diff-e401ae20091bbfb311a062c464f4f47fL23
>
> So the idea here is to change those dts files to only say <3 255> (patch
> 3), and add in a virtual 0% point at the bottom of the scale (patch 2).
>
> We have to do this conditionally because it seems some devices like to
> have the scale inverted:
> % git grep "brightness-levels\s*=\s*<\s*[1-9]"|cat
> arch/arm/boot/dts/tegra124-apalis-eval.dts: brightness-levels = <255 231 223 207 191 159 127 0>;
>
>
> Alexandru Stan (3):
> backlight: pwm_bl: Fix interpolation
> backlight: pwm_bl: Artificially add 0% during interpolation
> ARM: dts: rockchip: Remove 0 point in backlight
>
> arch/arm/boot/dts/rk3288-veyron-jaq.dts | 2 +-
> arch/arm/boot/dts/rk3288-veyron-minnie.dts | 2 +-
> arch/arm/boot/dts/rk3288-veyron-tiger.dts | 2 +-
> drivers/video/backlight/pwm_bl.c | 78 +++++++++++-----------
> 4 files changed, 42 insertions(+), 42 deletions(-)
>
> --
> 2.27.0
>
Hello,
Friendly ping.
Let me know if you would like me to make any changes to my patches.
Thanks,
Alexandru M Stan
On Mon, Jul 20, 2020 at 09:25:22PM -0700, Alexandru Stan wrote:
> After the "PWM backlight interpolation adjustments" patches, the
> backlight interpolation works a little differently. The way these
> dts files were working before was relying on a bug (IMHO).
>
> Remove the 0-3 range since otherwise we would have a 252 long
> interpolation that would slowly go between 0 and 3, looking really bad
> in userspace.
>
> We'll still have the 0% point available to userspace, "backlight:
> pwm_bl: Artificially add 0% during interpolation" takes care of that.
>
> Signed-off-by: Alexandru Stan <[email protected]>
Hmnn... almost wish I hadn't seen this ;-)
This basically says that your first patch will produce some odd
behaviour for existing device trees! On the other hand I strongly
suspect this trick is only currently seen on Chromebooks (since IIRC
that's where backlight animation is popular).
To be clear I'm entirely in favour of the changes in this patch... I
just dubious about combining it with artifically adding that 0%
Daniel.
> ---
>
> arch/arm/boot/dts/rk3288-veyron-jaq.dts | 2 +-
> arch/arm/boot/dts/rk3288-veyron-minnie.dts | 2 +-
> arch/arm/boot/dts/rk3288-veyron-tiger.dts | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/rk3288-veyron-jaq.dts b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> index 171ba6185b6d..af4b21636c08 100644
> --- a/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> +++ b/arch/arm/boot/dts/rk3288-veyron-jaq.dts
> @@ -20,7 +20,7 @@ / {
>
> &backlight {
> /* Jaq panel PWM must be >= 3%, so start non-zero brightness at 8 */
> - brightness-levels = <0 8 255>;
> + brightness-levels = <8 255>;
> num-interpolated-steps = <247>;
> };
>
> diff --git a/arch/arm/boot/dts/rk3288-veyron-minnie.dts b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
> index 383fad1a88a1..b25aa2f3cbee 100644
> --- a/arch/arm/boot/dts/rk3288-veyron-minnie.dts
> +++ b/arch/arm/boot/dts/rk3288-veyron-minnie.dts
> @@ -39,7 +39,7 @@ volum_up {
>
> &backlight {
> /* Minnie panel PWM must be >= 1%, so start non-zero brightness at 3 */
> - brightness-levels = <0 3 255>;
> + brightness-levels = <3 255>;
> num-interpolated-steps = <252>;
> };
>
> diff --git a/arch/arm/boot/dts/rk3288-veyron-tiger.dts b/arch/arm/boot/dts/rk3288-veyron-tiger.dts
> index 069f0c2c1fdf..52a84cbe7a90 100644
> --- a/arch/arm/boot/dts/rk3288-veyron-tiger.dts
> +++ b/arch/arm/boot/dts/rk3288-veyron-tiger.dts
> @@ -23,7 +23,7 @@ / {
>
> &backlight {
> /* Tiger panel PWM must be >= 1%, so start non-zero brightness at 3 */
> - brightness-levels = <0 3 255>;
> + brightness-levels = <3 255>;
> num-interpolated-steps = <252>;
> };
>
> --
> 2.27.0