Hi, On Mon, Dec 18, 2017 at 5:31 AM, Daniel Thompson <daniel.thomp...@linaro.org> wrote: > I think two different values on the userspace side should always map to > different values on the kernel side.
This is what I thought originally, but I believe I've convinced myself that this contradicts other goals and therefore needs to be relaxed. Specifically: Goal #1: A linear adjustment in the number exposed to userspace should result in a linear increase in human perceived brightness. Goal #2: Don't needlessly throw away precision available to the hardware. For instance, if the hardware only supports 64, 128 or 256 levels, it seems like a worthy goal to make sure that userspace can access each of these brightness levels. So if we accept that #1 and #2 are goals, the only solution is to expose a larger "virtual" space and have more than one user-exposed value map to the same actual brightness. As a very simple example, let's say we have a backlight that allows 8 levels: 0 = black 1 = 20% user brightness 2 = 40% user brightness 3 = 60% user brightness 4 = 75% user brightness 5 = 85% user brightness 6 = 90% user brightness 7 = 95% user brightness 8 = 100% user brightness What should we do here? We certainly couldn't expose 8 levels to the user since that would be very non-linear. What about if we exposed 6 levels? We could do: 0%, 20%, 40%, 60%, 85%, 100% That's mostly linear, but the 85% is a little wrong. We've also thrown away the ability for the user to access 90% and 95%, which seems non-ideal. IMHO better in this case is is to expose 101 values to userspace (including 0 and 100) and accept the fact that when the user specifies 10% and 11% that it won't change anything in the hardware. Now, I suppose that throwing away a few values if a PWM has 65536 levels is maybe not the end of the world, but I guess it also depends a lot on which levels you're throwing out. If we have this: 0 = black 1 = 5% user brightness 2 = 10% user brightness 65534 = 99.99% user brightness 65536 = 100% user brightness If we kept things linear (and didn't duplicate) in this case, we'd only expose 21 different level. 0, 5%, 10%, ..., 95%, 100%. IMHO it's better to duplicate. Once we've accepted duplication, I'd say it's easier to just pick a number of levels (4096?) and expose that to the user. If we wanted to be more friendly to the user, we could perhaps somehow expose the actual value, too. For instance, in the above example with 8 levels if the user set the brightness to "11", we could somehow expose to userspace that the brightness actually became "20". > This should make it possible > to calculate the maximal number of steps by scaling up the table to the > PWM resolution and then scanning for the smallest interval between > table steps. > > Once we have a maximal value we could either use it directly or we > might want to push it through min(calculated_max, 1024), on the > assumption that even for animated changes to backlight level that > 1024 is a sensible limit[1] > > > [1] I think it is... I'd be interested to know of Doug A. shares this > view.. I'm not not an expert at all, I just pretend sometimes (though usually I don't even pretend and just bask in my ignorance). Somehow it sticks in my mind that 4096 would be a good value, but I have no real evidence to back that up. ...but, that being said, let's see if I can come up with an excuse for 4096. My overall goal is that you want to be able to adjust the brightness without the user noticing each step. Users can definitely notice a step at 256 levels since that's widely quoted as roughly the number of levels that the human can perceive. I'd double it to be sure (hey, people pay for 48-bit color, don't they?), so let's say that a user could perceive 512 steps. My initial thought is that you'd want to animate, maybe 8 steps, between each perceivable point, which would get to 4096. ...but now that I say it, it does seem like technically you could get away with moving 1/1024, waiting, then the moving another 1/1024. In theory, the user shouldn't notice each step and it should be just as smooth as making 8 steps. ...so I guess I've convinced myself that 1024 should be enough. If I were designing it I'd probably still pick 4096 anyway just because I see no downsides and I could sorta believe that somehow my argument is wrong, but I won't yell if you pick 1024.
