brightness problems after suspend to ram
I have a Lenovo IdeaPad S540-13ARE with Ryzen 4800U. Brightness adjustment essentially works fine. However, there are certain problems that will be triggered with a suspend-to-ram/resume cycle.
First of all, the laptop has brightness adjustment keys that seemingly have low-level "roles" (i.e. other than emitting key codes to OS that would be mapped with XF86MonBrightnessDown/XF86MonBrightnessUp key syms) that would be active based on the current brightness -- if it is 0 / the lowest, the brightness down key will be a power off key for the monitor (literally like one on a desktop monitor; NOT DPMS off), and the brightness up will be a power on one. I'm not sure how low-level exactly this is but I guess it sort of works directly with the UEFI (or EC whatsoever).
However, the current amdgpu driver seems to have problem exposing the current brightness (to low level) or so. While you can still adjust brightness fine, now the "special role" of the brightness keys are active regardless of the current brightness.
At first I thought this was a UEFI firmware issue, because the problem can be observed on Windows as well. Yet later I found that, the problem only occurs if I'm using the current recommended (21.4.2) driver from AMD's website, but not an older version on the Microsoft / Windows Update repository.
A soft/warm reboot can restore the "conditional" nature of the special roles of the keys.
Here are some other abnormal behavioral changes that can be observed after a suspend/resume cycle:
- In
/sys/class/backlight/amdgpu_bl0/
, value inactual_brightness
will be changed to some certain value and no longer be updated to the the value inbrightness
when that is changed later. (That certain value seems to be in a different scale or range, like it will be 237 for 255, 32 for 34, etc.) But again this does not prevent the "physical" brightness from changing as requested. - Not sure if this is related to the above. Normally the brightness level 0 (the lowest) does NOT power off the monitor. However, it does after the cycle (as far as I can tell by my eyes). Note that this seems to be a different state from the one that triggers with the aforementioned power off triggered by the key, as the the brightness up key will NOT turn it back on (only when XF86MonBrightnessUp is not bound to adjust brightness by any means, of course).
P.S. I unbound XF86MonBrightnessDown/XF86MonBrightnessUp from doing anything when I was investigating the problems above. (I'm not using any DM/DE, only i3-wm and some xinit wrapper.)
OS: Arch Linux (and Windows 10 :P) | Kernel version: 5.12.9-arch1-1 / 5.10.43-1-lts