AMD Ryzen 4800H Renior iGPU backlight brightness control not working (Hybrid Graphics) (Lenovo Legion 5 15ARH05)

Brief summary of the problem:

Brightness control does not work with AMD Ryzen 4800H Renior iGPU when using switchable graphics (aka. Hybrid graphics). The value of /sys/class/backlight/amdgpu_bl0/actual_brightness is stuck at 311. Brightness control only works with discrete graphics card. Brightness control somewhat worked with Fedora Workstation 32 with Linux Kernel 5.6.6 but now with 5.10.4 brightness control does not work.

Hardware description:

• CPU: AMD Ryzen 7 4800H with Radeon Graphics
• GPU: NVIDIA 1650 Ti Mobile Graphics
• System Memory: 8 GB
• Display(s): Only one (Laptop Screen)
• Type of Diplay Connection: eDP

System infomration:

• Distro name and Version: OpenSUSE Tumbleweed
• Kernel version: 5.10.4
• AMD package version: 19.1.0-3.3 (xf86-video-amdgpu)

How to reproduce the issue:

Enable Switchable Graphics from BIOS and restart. Now you should have AMD iGPU and NVIDIA dGPU enabled. By default the panel uses iGPU for everything and offloads large graphical apps to dGPU.

Now try to change the brightness with software, Fn keys and changing /sys/class/backlight/amdgpu_bl0/brightness and the brightness will not change, i.e The brightness control will not respond and the brightness will always be at max.

It is worthy to note that the value of /sys/class/backlight/amdgpu_bl0/actual_brightness is stuck at 311 and does not change at all.

When using only the discrete graphics card the brightness control works perfectly.

changed the description

changed the description

Do these patches help?

https://cgit.freedesktop.org/~agd5f/linux/commit/?h=backlight_wip&id=46da1807c2e3e6fe8c224b07d4a3869e42267925

https://cgit.freedesktop.org/~agd5f/linux/commit/?h=backlight_wip&id=dfe5c48f6433c88f988da19a356067405740a3a3

A bit more debugging has been done in the openSUSE bugzilla entry https://bugzilla.opensuse.org/show_bug.cgi?id=1180749

And there we found out that the aux backlight doesn't work for this machine at all. So, your patches will fix the sysfs value read problem, but the actual backlight control will be still broken.

That said, either something is missing in the aux backlight control code, or it was wrongly detected as if the aux backlight works, I suppose.

@agd5f Sorry for the late reply. As @tiwai said the brightness control now works with a hack which completely forces to disable aux support. So the driver wrongly detects that aux is supported but it's not, so when backlight is adjusted it uses aux but aux is not supported so the brightness is never actually changes.

@agd5f This line -> https://github.com/torvalds/linux/blob/5695e51619745d4fe3ec2506a2f0cd982c5e27a4/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L2265 is the culprit for this entire bug.

Forcing caps->aux_support = false; will fix this issue. Currently the code simply declares the device has aux support simply if it has oled, this makes no sense in my opinion (But I might be wrong, the amd guys might know better than me.)

I can confirm that forcing caps->aux_support = false allows adjusting the backlight on a Lenovo Ideapad Gaming 3 15ARH05 with Ryzen 4600H after removing that assignment in kernel 5.11.2. I am not sure how this relates to OLEDs, given that none are involved?

Is there anything to do that I could help with to get this fixed in mainline?

What exactly did you change? Did you just remove the caps->ext_caps->bits.oled == 1 check or did you just force caps->aux_support = false? Do the attached patches fix it?

0001-drm-amdgpu-display-dm-drop-oled-check-for-aux-backli.patch

0002-drm-amdgpu-display-dc-drop-oled-check-from-backlight.patch

For completeness: On my machine, just removing the OLED part doesn't help, I had to remove the whole if-statement from amdgpu_dm.c (not sure which of the other flags was active); but the amdgpu.backlight=0 will handle that. What's the ETA, kernel 5.12 or later?

@agd5f I simply implied that the check for aux support is not fool proof. The check needs to be more robust and reliable. At least have an option to force disable aux support in mainline linux. Maybe a kernel option like how @tiwai implemented in his fix?

I'm trying to understand the details of your laptop so we can fix this properly.

@tiwai and I did a debug and this is the ext_cap value that was used,

[    7.872674] amdgpu: XXX ext_caps=0xa7

This is the value used in this line -> https://github.com/torvalds/linux/blob/f69d02e37a85645aa90d18cacfff36dba370f797/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c#L2265

@agd5f I only know that the value of ext_caps->raw = 0xa7 which is the binary combination -> 10100111 and this combination decides if the display has aux support or not. There is some fault in the detecting the correct hardware, this is the struct in question-> https://github.com/torvalds/linux/blob/d99676af540c2dc829999928fb81c58c80a1dce4/drivers/gpu/drm/amd/display/dc/dc.h#L1105

Your display indicates that it uses aux backlight control. Presumably the OEM chose not to use the aux control for some reason and never updated the DPCD info.

Your display indicates that it uses aux backlight control. Presumably the OEM chose not to use the aux control for some reason and never updated the DPCD info.

@agd5f All Lenovo Legion 5 AMD version(I think intel versions are affected too, I can't confirm without testing) and Lenovo Ideapad Gaming AMD version has this issue. Can we make any workaround which can be accepted into the mainline kernel??? Or our only chance is to use patched linux kernels forever? Can we sort of make a test if the backlight control actually worked when using aux control and if not fallback to not using aux?

EDIT: Most likely the driver is reading the DPCD info wrongly.

I think in eDP displays we have to check if it supports both aux and PWM pin, if it does then we have to prefer PWM pin over the aux. A kernel param to force use PWM pin would be nice. It is worthy to note that even in ASUS TUF(AMD Version) laptops, this issue also exists.

mentioned in commit agd5f/linux@7c209847

@agd5f Thanks for the quick fix. I really hope to speak to the folks at Lenovo or ASUS to talk about this issue but it seems they don't care about linux or open source which is sad. I've tested the latest changes and everything seems to work just fine.

@luzat With the latest commit from @agd5f and @tiwai you can now use this fix with the kernel param amdgpu.backlight=0

mentioned in commit agd5f/linux@7a46f05e

This problem seems to happen on various laptops with ADM/NVIDIA switchable graphics, but not on laptops with just AMD GPU. I have not seen anyone report it on laptop without NVIDIA GPU, and it works correctly on my laptop with just AMD iGPU. Is there any laptop with switchable graphics where this issue doesn't occur? If no, the workaround could be applied to all systems with NVIDIA GPU.

@agd5f It is true that this issue happens in a lot of laptop with switchable graphics as said by @filip-hejsek

Is there any progress in finding the root of this bug??. This specific bug occurs only with switchable graphics which uses a mux. But I'm really glad that we got a workaround in the mainline kernel.

Hi. I'm use Lenovo ideapad gaming 3 (ryzen 7 4800h & gtx1650ti). I guess you found a temporary solution, but I don't understand how you did it. I've been dealing with this issue for days, how can I solve this issue? I would be glad if you help.

You should probably upgrade to a kernel version of 5.11.7 or higher (if you don't want to patch your kernel). How exactly depends on your distribution or how you build your own kernel.

You will also need to add amdgpu.backlight=0 to your kernel command line. For Debian and probably Ubuntu with Grub bootloader this can be done by setting GRUB_CMDLINE_LINUX="amdgpu.backlight=0" in /etc/default/grub and running update-grub afterwards (as root). See also at https://unix.stackexchange.com/questions/616371/backlight-control-not-working-on-lenovo-ideapad-gaming-3-with-renoir-amdgpu/637154#637154

If you need specifics, you'd need to add details about your configuration (not sure if I could help with other distros, though).

Thank you so much

Hi, again. in Pop_OS 21.04 have no grub file, also ı couldn't find the amdgpu_dm.c file. i upgraded kernel version 5.13. What should I do?

It's probably using systemd-boot. I don't have experience with that, but you probably need to adjust some .conf file in /boot/loader/entries and add the missing kernel option like:

options root=... quiet amdgpu.backlight=0

You may also want to try adding the option during boot (probably by pressing e to edit the entry) temporarily to check if it's working. Please note that erroneous changes may leave your system unbootable. Try to read some documentation first (like https://support.system76.com/articles/bootloader/ https://wiki.archlinux.org/title/Systemd-boot https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/ ). If you have any more problems, you should probably ask in a more appropriate forum for Pop!_OS on how to add kernel boot parameters.

Thank you so much for your insterest ve answers. i will try

I was able to get brightness control by adding "RegistryDwords" "EnableBrightnessControl=1" to the nvidia xorg.conf file but I also had to set dedicated graphics in the bios which has not been great for battery life. https://wiki.archlinux.org/title/NVIDIA#Enabling_brightness_control

Probably it would be better to edit the grub file. I removed the systemd-boot package and installed grub, then edited the /etc/default/grub file and fixed the problem. But overall I found that Pop!_OS consumes more battery than Windows.

mentioned in commit agd5f/linux@bbbcf1eb

mentioned in commit agd5f/linux@d0ae0b64

mentioned in commit agd5f/linux@f2ad3acc

mentioned in issue #1671 (closed)

mentioned in commit nouveau@bb65051d

mentioned in commit nouveau@37d363b3

@agd5f In Linux version 5.14.14, I can get brightness control in hybrid mode without the use of the kernel parameter amdgpu.backlight = 0. I don't know which version of linux fixed it exactly. But it seems to be fixed.

closed

mentioned in issue #1791 (closed)