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
| ||
|
Date: Fri, 4 Sep 2020 12:43:49 +0100 From: Daniel Thompson <daniel.thompson@...aro.org> To: Alexandru Stan <amstan@...omium.org> Cc: Thierry Reding <thierry.reding@...il.com>, Uwe Kleine-König <u.kleine-koenig@...gutronix.de>, Lee Jones <lee.jones@...aro.org>, Jingoo Han <jingoohan1@...il.com>, Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>, Heiko Stuebner <heiko@...ech.de>, Rob Herring <robh+dt@...nel.org>, Matthias Kaehlcke <mka@...omium.org>, Douglas Anderson <dianders@...omium.org>, Enric Balletbo i Serra <enric.balletbo@...labora.com>, devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, linux-rockchip@...ts.infradead.org Subject: Re: [PATCH 3/3] ARM: dts: rockchip: Remove 0 point in backlight 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 <amstan@...omium.org> 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
Powered by blists - more mailing lists