[Bug 85861] backlight control doesn't work on Lenovo t440p after upgrading to 3.17 [bisected]

[bugzilla-daemon at bugzilla.kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=85861

--- Comment #24 from Jani Nikula <jani.nikula at intel.com> ---
(In reply to Tommi Kyntola from comment #23)
> What are the semantics behind the 'actual_brightness' then?

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/stable/sysfs-class-backlight

> Are there cases where  it can indeed differ from the set value in
> 'brightness' in some reasonable way outside of rounding errors?

actual_brightness is queried from the hardware. The brightness in the hardware
may be represented with something completely different from a linear range from
0..max_brightness. Also, the BIOS might (and has been known to) change the
value behind our back.

> (it'd be nice to know if anyone is thinking about informing the kde people
> about all this)
> 
> Why is it necessary to even try do the inverse for the scaling, because with
> integers that simply is not a bijection unless the ranges are of equal size?

Because the interface expects a range 0..max_brightness.

> The commit in comment #14 works only by chance here, too, because with the
> minimum set the ranges aren't of equal size and indeed in many spots the
> brightness and actual_brightness again show different values, which would
> break kde powerdevil.
> 
> The commit in comment #11 is of course different and retains the identical
> ranges and make the scaling and identity operation and thus leave no room
> for rounding errors of any kind.
> 
> Why not store the user value and return that for the reverse when asked for?
> I tried that with quadratic scaling and it works like a charm all along the
> range quite nicely (*), in fact, I'm likely to keep that patch in my own
> laptop. I can clean it up a notch and sign-off, if anyone's interested.
> 
> (*) Well, I did add the inverse quadratic scaling there, too, but I only
> went for it if the previous values that passed through scale could not be
> used, i.e. only if there was a cache miss in a sense. Turns out, there's
> only one miss and that's during a boot which is non-ciritical and could
> probably be avoided, too.

If the userspace wants the value it stored, it can use brightness...

-- 
You are receiving this mail because:
You are on the CC list for the bug.