On Fri, Feb 5, 2021 at 6:27 PM Daniel Thompson <daniel.thompson@xxxxxxxxxx> wrote: > On Tue, Jan 26, 2021 at 10:32:00PM +0100, Linus Walleij wrote: > > The KTD253 backlight might already be on when the driver > > is probed: then we don't really know what the current > > ratio is and all light intensity settings will be off > > relative to what it was at boot. > > > > To fix this, bring up the backlight OFF then move it to > > the default backlight from there so we know the state. > > > > Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx> > > Hmnnn... horid, since the backlight will flicker during boot, > but I recall that this bit of hardware is pretty horid anyway > so it is not easily avoided. > > Therefore, slightly grudgingly, > Reviewed-by: Daniel Thompson <daniel.thompson@xxxxxxxxxx> Thanks, and I agree, this makes things better than before though. The actual problem translates to the generic problem of bringing misc boot-time conditions over to the kernel, and handing over any type of hardware in a half-initialized state. We don't really have a solution to that yet, many have tried. For this specific case, one can imagine a "kinetic,boot-time-brightness" (or similar) DT property, with the idea that the boot loader or DT author knows what to put in there. I put that on my TODO (the code in this patch will still needed if that property isn't provided). Yours, Linus Walleij _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
