A long time ago (I *think* around 4.8/4.9) I noticed that my usual PWM values no longer corresponded to the physical amount of light produced by my screen. A value of 1/937 which used to be ultra-dim was quite bright. The cause of this was never found (Various PWM/brightness related commits at that time reverted, to no avail). Today I decided to try and invert the brightness via 'invert_brightness' in sysfs and set the brightness to 936/937 - and there was the old ultra-dim brightness I have seen before at 1/937. What I think is happening is that the PWM range is shifted up, causing the lowest PWM value to correspond to ~40+ of the old, correct range. The highest PWM value seems to still clamp to 937, as that seems to be the hw limit. This causes the whole PWM range to be incorrect, not only disallowing low brightness values, but also losing precision (Incorrect range is effectively lower than 1-937). tl;dr: Normal 1/937 much brighter than inverted 936/937. The latter being the original correct brightness produced by 1/937. Sysinfo: Haswell Intel i7-4500U with HD 4400, eDP laptop display. next-20170519 (Happens on ~4.9+)
This patch [1] fixes the inverted range to be the same as the non-inverted range. I know that's not what you were after, but that's a bug we have and you (perhaps inadvertently) reported. The VBT lists the minimum brightness to be used for the backlight. Historically we ignored that, until it caused real issues on some board designs. A low enough PWM duty cycle would pull down other signals on the eDP connector, causing black screens, IIRC. The VBT minimum is there for the OEM to specify. Obviously it also means you can't go as dim as you used to be able to go. As to the brightness range reduction, it doesn't really matter. You'll only have maybe 100-300 user distinguishable luminance levels anyway, depending on the PWM modulation frequency and other factors. More important would be to add support to account for the non-linearity of the luminance as a function of the PWM duty cycle. Please test the patch and see if that fixes the inconsistency between inverted and non-inverted backlight brightness. [1] http://patchwork.freedesktop.org/patch/msgid/20170531083355.7898-1-jani.nikula@intel.com
Looks like there is a patch submitted
(In reply to Ricardo from comment #2) > Looks like there is a patch submitted Again, we only resolve/close bugs fixed *after* the patches have actually been merged upstream. In this case, it was not until today. commit e9d7486eac949f2a8d121657e536c8abdd4ea088 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed May 31 11:33:55 2017 +0300 drm/i915: fix backlight invert for non-zero minimum brightness
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.