https://bugzilla.kernel.org/show_bug.cgi?id=203439
Bug ID: 203439 Summary: amdgpu: [REG 4.20 -> 5.0] Brightness minimum level is too high Product: Drivers Version: 2.5 Kernel Version: 5.0 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri@kernel-bugs.osdl.org Reporter: spaz16@wp.pl Regression: No
I have Huawei Matebook D 14 with AMD Ryzen 2500U.
Since kernel 5.0.x the minimum brightness level is too high. It is not possible to dim the display as much as on previous kernel version. Kernel 4.20 also allows to disable the backlight on level 0.
Value of "0" in "/sys/class/backlight/amdgpu_bl0/brightness" currently doesn't disable backlight as in previous version. Value of "1" means the screen is dim, but not as much as in kernel 4.20. Sometimes the screen is still too bright even on level 0 in kernel 5.0.
Since commit 206bbafe00dcacccf40e6f09e624329ec124201b I can see the define:
#define AMDGPU_DM_DEFAULT_MIN_BACKLIGHT 12
Maybe it should be defined to "0" to restore the old behavior? (I haven't tested yet)
https://bugzilla.kernel.org/show_bug.cgi?id=203439
--- Comment #1 from Błażej Szczygieł (spaz16@wp.pl) --- *** Bug 203427 has been marked as a duplicate of this bug. ***
https://bugzilla.kernel.org/show_bug.cgi?id=203439
Nicholas Kazlauskas (nicholas.kazlauskas@amd.com) changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nicholas.kazlauskas@amd.com
--- Comment #2 from Nicholas Kazlauskas (nicholas.kazlauskas@amd.com) --- At some point we started reading the ACPI backlight caps to respect the actual backlight range for the panel. We map the backlight level specified by the user from 0-255 to that range.
In the case where the caps aren't valid we use a default minimum brightness that's non-zero since some panels will flash when the backlight level goes to zero.
While I don't know offhand the reasoning for 12 specifically I also don't think we'll be dropping it back down to zero.
Wouldn't DPMS off give you what you want in this case?
https://bugzilla.kernel.org/show_bug.cgi?id=203439
--- Comment #3 from Błażej Szczygieł (spaz16@wp.pl) --- Thank you for the reply!
In bright room you can quickly disable the backlight (set it to 0) using the Fn+F1 keys. You can save power and the display content doesn't disturb you, but you can still notice that computer is working (the screen content can be still visible). It is more convenient than DPMS, especially if you have duplicated screen with HDMI and you don't want to reconfigure anything, just you want to quickly disable the backlight.
Moreover, the current minimum backlight level is too bright for very dark room. Sometimes I need to set to value of "2" or even "1" in kernel 4.20. Since kernel 5.0 it is not possible and I'm not feeling convenient with too bright display.
On Huawei Matebook D 14 the display doesn't flicker at all even on brightness level 1 on kernel 4.20 (no PWM). Maybe it is a good idea to blacklist or whitelist some devices? Or maybe it is a good idea to add an additional kernel parameter to restore the old behavior and unlock all possible backlight levels for more advanced users?
https://bugzilla.kernel.org/show_bug.cgi?id=203439
acomagu@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |acomagu@gmail.com
--- Comment #4 from acomagu@gmail.com --- I also need this fix.
As Błażej Szczygieł says, the minimum backlight level is too bright at night for me. That's why I'm staying at 4.19 instead of 5.x.
I hope anyone considers better strategy like based on such device list.
https://bugzilla.kernel.org/show_bug.cgi?id=203439
--- Comment #5 from acomagu@gmail.com --- I forgot to mention about my device. I'm using HP Envy 13 x360(ag0000).
https://bugzilla.kernel.org/show_bug.cgi?id=203439
Anish Sapkota (sapkotaanish000@gmail.com) changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sapkotaanish000@gmail.com
--- Comment #6 from Anish Sapkota (sapkotaanish000@gmail.com) --- I am still facing this problem in Acer Aspire 5. Are there any updates to it?
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠bugzilla.kernel.org