[Bug 85861] backlight control doesn't work on Lenovo t440p after upgrading to 3.17 [bisected]
bugzilla-daemon at bugzilla.kernel.org
bugzilla-daemon at bugzilla.kernel.org
Mon Oct 27 03:11:52 PDT 2014
https://bugzilla.kernel.org/show_bug.cgi?id=85861
--- Comment #26 from Tommi Kyntola <kynde at ts.ray.fi> ---
> The brightness in the hardware may be represented with something completely different from a linear range from 0..max_brightness.
But actual_brightness is transferred back to user values and it's this scale
that I'm questioning.
And I understand why the scale from user to hw is needed, but it was the
inverse that I was questioning, but this next point makes it clear:
> Also, the BIOS might (and has been known to) change the value behind our back.
Ok, in that case indeed the most sensible thing to do, would be for userspace
to not demand accurate actual_brightness wrt to brightness.
Although, a lot confusion could be avoided by caching the user input and
spewing that out as actual_brightness if the values match, which is what I'm
doing right now. (I cache the scale_quad input and output and then for
actual_brightness in scale_quad_inv I check if what the hardware is returing
that said scale output then it's safe and correct to return the earlier cached
scale input. And if they don't match (as is the case during the boot and would
be in abrupt BIOS tweaks to brightness) then compute the inverse quad, which
obviously cannot be made one-to-one. The fact that I'm using quad scale is
irrelevant here, because same problems are currently there with the 57..4437
hardware scale and the 0..4437 user scale.
Another way to by-pass these problems for now would be do the minimum
brightness by a user max value reduction guaranteeing equal ranges and
one-to-one mappings across the whole domain.
> Because the interface expects a range 0..max_brightness.
Oh, I get that, I was merely questioning if the hardware value ever changes on
its own, because if not, then indeed caching the setting from user_to_hw would
be sufficient.
> A mystery, at a glance, powerdevil does not use actual_brightness.
Someone sure does as I can see quite a number of calls to scale (I have some
printk's in there) whenever I touch the Fn-brightness buttons. And as i have
the split it into scale_quad and scale_quad_inv for user_to_hw and hw_to_user,
respectively, I can pretty much tell that someone sets 'brightness' and then
checks up on 'actual_brightness' to match that setting.
And if they fail in a way that actual_brightness doesn't match what was just
set to brightness then further calls to Fn-brightness fail.
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the intel-gfx-bugs
mailing list