On Tue, Jun 11, 2019 at 3:49 AM Daniel Thompson <daniel.thompson@xxxxxxxxxx> wrote: > This is a long standing flaw in the backlight interfaces. AFAIK generic > userspaces end up with a (flawed) heuristic. Bingo! Would be nice if we could start to fix this long-standing flaw. > Basically devices with a narrow range of choices can be assumed to be > logarithmic That's (almost, see below) exactly what we have. (And this is what Matthias is fighting against, now that we're implementing both "large number of data points" and "pre-curved" at the same time. We will have to either adapt the heuristic, or else adapt our device trees to fit the heuristic.) > Systems are coming along that allow us to animate the change of > brightness (part of the reason for interpolated tables is to > permit smooth animation rather than because the user explicitly wants > to set the brightness to exactly 1117). Chrome OS has done this for a long time. So "coming along" is a bit late ;) Also, I believe Chrome OS will do animation/smoothing for all tables (small or large) where it can: even for the small tables. > These systems are often > logarithmic but with a wide range of values. NB: Chrome OS happens to use a polynomial formula (exponent = 2 or 0.5, depending on how you look at it), not logarithmic. You can see it in all its (non)glory here: https://chromium.googlesource.com/chromiumos/platform2/+/ee015853b227cf265491bd80ccf096b188490529/power_manager/powerd/policy/internal_backlight_controller.cc#451 Regards, Brian
