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 :
> [email protected] 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
This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.
Developers: When fixing the issue, remember to add 'Link:' tags pointing
to the report (e.g. the buzgzilla ticket and maybe this mail as well, if
this thread sees some discussion). See page linked in footer for details.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
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 :
>
>> [email protected] 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
On 14.02.23 15:59, Hans de Goede wrote:
>
> 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 :
>>
>>> [email protected] 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.
yw
> I have just added the following comment to the bug:
> [...]
> Lets continue this inside bugzilla.
Thx. FWIW, at least from my side there is no need to post replies to
bugzilla and the list; some developers prefer one, some the other -- and
regzbot will notice replies to both places.
It's IMHO unfortunate that we have to deal with two places, but well,
that's how it is.
Ciao, Thorsten
P.S.: while at it, let me tell regzbot that this one will take some time
to get resolved:
#regzbot backburner: known bios issue, that why there where tricky
aspects beforehand as well; someone from Nvidia is looking into this