Hi Thorsten, On 2/14/23 11:44, Linux regression tracking (Thorsten Leemhuis) wrote: > Hi, this is your Linux kernel regression tracker. > > I noticed a regression report in bugzilla.kernel.org. As many (most?) > kernel developer don't keep an eye on it, I decided to forward it by > mail. Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=217026 : > >> albimarini4283@xxxxxxxxx 2023-02-12 20:57:03 UTC >> >> Brightness control does not work with AMD Ryzen 5800H when using hybrid >> graphics on kernel updates 6.1.4+. I am using a Lenovo Legion Slim 7 >> (2021, 15ACH6) currently running Arch Linux with the mainline kernel >> 6.1.11, however, I have been testing my experience with this issue on >> every point revision from 6.1.3 to 6.1.11. >> >> CPU: AMD Ryzen 5 5800H with Radeon Graphics >> GPU: NVIDIA RTX 3060 Mobile / Max-Q (Proprietary NVIDIA driver, >> tested with 525.78.01-1 (version prior to 6.1.4 being released) and >> 525.89.02-1 (latest driver at time of writing)) >> System Memory: 40 GB >> Display: Laptop (Laptop Screen) >> >> The only parameters applied at boot on my system are: nvidia-drm.modeset=1 >> >> How to reproduce the issue: >> Enable hybrid graphics/Optimus in BIOS setup. >> >> Prior to kernel version 6.1.4, /sys/class/backlight contained two entries: >> amdgpu_bl0 and nvidia_wmi_ec_backlight >> >> With these two entries in /sys/class/backlight , I was able to write to >> their respective brightness files directly or use a program like light >> to change the values. Those values would change the brightness of the >> screen depending on if I was using the AMD GPU or NVIDIA GPU to display >> the current application. I could set these values to roughly the same >> thing to achieve an overall complete brightness experience regardless of >> whether or not I was currently running an application on my integrated >> (AMD) GPU or dedicated (NVIDIA) GPU. >> >> Then, upon updating to kernel versions 6.1.4+, there is no longer an >> amdgpu_bl0 entry in /sys/class/backlight , just a >> nvidia_wmi_ec_backlight entry, making it impossible for me to change the >> brightness on my display when using the iGPU. Interestingly, on kernels >> 6.1.4+, running "journalctl -b -0 | grep backlight" returns an output >> "amdgpu: [drm] Skipping amdgpu DM backlight registration", which was not >> present in prior kernel versions. >> >> However, if I instead prepend the option "acpi_backlight=native" to my >> kernel command line options at boot, "amdgpu_bl0" is once again present >> in /sys/class/backlight but "nvidia_wmi_ec_backlight" has now >> disappeared and is nowhere to be seen making it so I can change the >> brightness when using the iGPU, but the brightness is stuck at max when >> using the dedicated GPU. Running the above journalctl command at this >> point returns no errors relating to my AMD GPU and does not mention >> anything about the NVIDIA GPU. Trying different acpi_backlight options >> on 6.1.4+ does not fix the issue and instead removes functionality. >> acpi_backlight=vendor makes an entry called "ideapad" pop up in >> /sys/class/backlight with nothing else. Changing the brightness values >> in ideapad does nothing. >> acpi_backlight=video makes only two entries appear in >> /sys/class/backlight, acpi_video0 and acpi_video1. Changing the >> brightness values in either of these directories does nothing. >> acpi_backlight=none causes nothing to appear under /sys/class/backlight. >> >> If hybrid graphics is disabled, the display is connected to the NVIDIA >> GPU and /sys/class/backlight/nvidia_0 is present, the NVIDIA driver can >> change the display brightness without a problem.p >> >> Below is my lscpi -nn and dmidecode outputs on kernel 6.1.3 and 6.1.11. >> [...] > > See the ticket for more details. > > [TLDR for the rest of this mail: I'm adding this report to the list of > tracked Linux kernel regressions; the text you find below is based on a > few templates paragraphs you might have encountered already in similar > form.] > > BTW, let me use this mail to also add the report to the list of tracked > regressions to ensure it's doesn't fall through the cracks: > > #regzbot introduced: v6.1.3..v6.1.4 > https://bugzilla.kernel.org/show_bug.cgi?id=217026 > #regzbot title: backlight: brightness control stopped working on a Ryzen > system with hybrid graphics > #regzbot ignore-activity Thank you for forwarding this. I have just added the following comment to the bug: """ Yes this has already been reported on the malinglist. There unfortunately is a firmware bug on the Lenovo Legion models. On models with the Nvidia WMI EC backlight interface, when the laptop is configured in dynamic mux mode in the BIOS (1) the backlight should always be controlled by the Nvidia WMI EC backlight interface. So in theory the kernel is behaving as it should according to the documentation here. But as you found out, some Legion models are not behaving as the Nvidia WMI spec says they should behave. This is also why you needed the hack/script to write brightness values to both backlight devices at the same time with older kernels. Daniel Dadap from Nvidia is looking into this, but I'm afraid that we don't have a solution yet. 1) So that you can switch at runtime which GPU is connected to the builtin LCD panel """ Lets continue this inside bugzilla. Regards, Hans
