Bug 1180749

Care to report to the upstream, e.g. gitlab.freedsktop.org Issues?
That's the official place for reporting.  I'll keep this bug opened in case we can do some backports based on the upstream devs.

(In reply to Takashi Iwai from comment #1)
> Care to report to the upstream, e.g. gitlab.freedsktop.org Issues?
> That's the official place for reporting.  I'll keep this bug opened in case
> we can do some backports based on the upstream devs.

I thought this is a bug with the amdgpu and radeon drivers in the linux kernel, is it not the case?? So it is a X.Org thing?

I'm a bit confused here. But I will try to talk with freedesktop folks.

Okay I can confirm that Fedora 32 with Linux Kernel version 5.6.6-300.fc32.x86_64  x86_64 GNU/Linux I can control the screen brightness but I can't do the workaround for the touchpad.

But in this version of the kernel we have cat /sys/class/backlight/*/actual_brightness constantly stuck to 2827 or something but still the brightness control works as expected. 

Did not try using the nvidia non-free drivers this one.

So I highly suspect that something happened between 5.6.6 and the mainline kernel.

(In reply to Antony J.R from comment #2)
> (In reply to Takashi Iwai from comment #1)
> > Care to report to the upstream, e.g. gitlab.freedsktop.org Issues?
> > That's the official place for reporting.  I'll keep this bug opened in case
> > we can do some backports based on the upstream devs.
> 
> I thought this is a bug with the amdgpu and radeon drivers in the linux
> kernel, is it not the case?? So it is a X.Org thing?

gitlab.freedesktop.org also the place where the kernel graphics guys use as the primary development place in general.  Use DRI/AMDGPU or such component there.

Actually, which backlight drivers are being used there?  Is it only ACPI or native driver?

And do I understand correctly that, if you switch to Nvidia driver (both mod setting and rendering), the backlight control works via /sys/class/backlight, while the same doesn't work if switching to AMDGPU?

(In reply to Takashi Iwai from comment #5)
> Actually, which backlight drivers are being used there?  Is it only ACPI or
> native driver?
> 
> And do I understand correctly that, if you switch to Nvidia driver (both mod
> setting and rendering), the backlight control works via
> /sys/class/backlight, while the same doesn't work if switching to AMDGPU?

To be exact, hybrid graphics brightness control does not work. Yes using only the discrete graphics card with nvidia non-free software enables me to control the backlight. But when switched to hybrid graphics(switchable graphics) the iGPU brightness control will not work.

With hybrid graphics disabled I have only /sys/class/backlight/nvidia_0 and brightness works correctly. But with hybrid graphics I have both /sys/class/backlight/amdgpu_bl0 and /sys/class/backlight/nvidia_0 . I can offload stuff to Nvidia graphics card and verify it with nvidia-smi but the brightness control is solely on the iGPU i.e in my case iGPU which is a Radeon graphics. This is known as Nvidia PRIME IIRC.

OK, then this sounds like a bug in amdgpu, indeed.  If so, gitlab.freedesktop.org is the right place to report.  Please go ahead :)

(In reply to Takashi Iwai from comment #8)
> OK, then this sounds like a bug in amdgpu, indeed.  If so,
> gitlab.freedesktop.org is the right place to report.  Please go ahead :)

Okay I've reported it to the upstream -> https://gitlab.freedesktop.org/drm/amd/-/issues/1438

I tested kernel version 5.11-rc6 from Kernel:HEAD and the brightness issue still exists. It seems like I should mainline this thing myself. Never expected this from amd, even NVIDIA drivers works great.

Kernel bug https://bugzilla.kernel.org/show_bug.cgi?id=203905

(In reply to Antony J.R from comment #11)
> Kernel bug https://bugzilla.kernel.org/show_bug.cgi?id=203905

I'm afraid that the above is a bit different issue.
The fix for the scaling problem was already included in 5.9 kernel.

We need starting the debug locally, at least to see what values are floating around there.

I'm building an amdgpu KMP with a debug print patch, targeted for Tumbleweed kernel.  Could you try the amdgpu-dbg-kmp-default from OBS home:tiwai:bsc1180749 repo, and give the dmesg output?

(In reply to Takashi Iwai from comment #13)
> I'm building an amdgpu KMP with a debug print patch, targeted for Tumbleweed
> kernel.  Could you try the amdgpu-dbg-kmp-default from OBS
> home:tiwai:bsc1180749 repo, and give the dmesg output?

Okay I've installed your package and rebooted with switchable graphics enabled, all the required logs are uploaded here -> https://github.com/antony-jr/lenovo-legion5-15arh05-scripts/tree/main/AMDGPUDebug

Also here is a very similar kernel bug -> https://bugzilla.kernel.org/show_bug.cgi?id=207833

Hm there is no added debug message.  Could you rebuild initrd (e.g. run mkinitrd) and retest?

Also, check the output of "modinfo amdgpu" after installing KMP.
The File section should show the directory with /lib/modules/.../updates/

(In reply to Takashi Iwai from comment #15)
> Hm there is no added debug message.  Could you rebuild initrd (e.g. run
> mkinitrd) and retest?

mkinitrd did the trick but now sddm does not start automatically for some reason so I have to do startx from tty but I can rollback.

The updated log is in the same location -> https://github.com/antony-jr/lenovo-legion5-15arh05-scripts/blob/main/AMDGPUDebug/dmesg.txt

For more debug info I tried to decrease the brightness to 0% and go to 100% again, hope that helps.

Thanks.  It shows that aux is used for the backlight control, and the values set there look OK through a quick glance.  While you tested the brightness, it didn't change actually, right?

Could you try to read the current brightness, and check the kernel log, too?

(In reply to Takashi Iwai from comment #18)
> Thanks.  It shows that aux is used for the backlight control, and the values
> set there look OK through a quick glance.  While you tested the brightness,
> it didn't change actually, right?
> 
> Could you try to read the current brightness, and check the kernel log, too?

Sorry for the late reply, the updated log is here => https://github.com/antony-jr/lenovo-legion5-15arh05-scripts/blob/main/AMDGPUDebug/dmesg.txt


I changed the brightness and did cat /sys/class/backlight/amdgpu_bl1/brightness and /sys/class/backlight/amdgpu_bl1/actual_brightness

Here the brightness changed when changed the brightness but actual_brightness is stuck at 311 constantly.

The kernel log also shows that the get brightness routine output is stuck at invalid values.

Thanks.  Then I misunderstood situation as if the backlight control didn't take any effect.

Now I refreshed the OBS KMP repo to contain the possible fix.  It's being rebuilt, and please give it a try later.  The rpm changelog should contain the entry like:
- Add a proper fix (attempt):
  0001-drm-amd-display-Fix-the-brightness-read-via-aux.patch

At first, uninstall the previous KMP, just do "zypper rm amdgpu-dbg-kmp-default"
Then re-install the new rpm, run mkinitrd and retest.  This doesn't contain the debug prints, so report back whether it works or not.

(In reply to Takashi Iwai from comment #20)
> Thanks.  Then I misunderstood situation as if the backlight control didn't
> take any effect.
> 

I mean the backlight is constantly at maximum brightness and I can't decrease or control it. The only thing works is the brightness slider in OpenSUSE and the brightness value is only reflected in /sys/class/backlight/amdgpu_bl0/brightness file but the backlight does not change at all. I think I misled you saying "Here the brightness changed when changed the brightness but actual_brightness is stuck at 311 constantly.", Here I said /sys/class/backlight/amdgpu_bl0/brightness changes when I change the brightness slider in the OS (or Fn Keys) but the backlight still remains at maximum brightness. 

> Now I refreshed the OBS KMP repo to contain the possible fix.  It's being
> rebuilt, and please give it a try later.  The rpm changelog should contain
> the entry like:
> - Add a proper fix (attempt):
>   0001-drm-amd-display-Fix-the-brightness-read-via-aux.patch
> 
> At first, uninstall the previous KMP, just do "zypper rm
> amdgpu-dbg-kmp-default"
> Then re-install the new rpm, run mkinitrd and retest.  This doesn't contain
> the debug prints, so report back whether it works or not.

I will report back ASAP.

It seems the package at the repo is not updated, I will try once it updates -> https://download.opensuse.org/repositories/home:/tiwai:/bsc1180749/standard/

It's because of a mistake in the previous packaging.  Now fixed and it's built, but the publishing seems taking long.

You can fetch the fresh package directly via osc command before publishing, too:
  osc getbinaries home:tiwai:bsc1180749/amdgpu-dbg/standard/x86_64

Okay, I've tested with your possible fix. But it did not work. Now /sys/class/backlight/actual_brightness reports valid values which is the same as /sys/class/backlight/brightness 

Now when I change the brightness both /sys/class/backlight/actual_brightness and /sys/class/backlight/brightness reports valid values but still the display brightness is at maximum and does not change.

Seems like this is not a easy fix.

OK, then you're hitting multiple issues, as it seems.

The inconsistent value read from sysfs was addressed by my patch.  But, I suppose that the main reason of the non-functional backlight is that the driver misdetected the backlight control over aux.

I refreshed again the KMP with a hack patch to disable the aux support.  Please give it a try later again.  This will show a line "XXX ext_caps=0x..." in kernel log.

(In reply to Takashi Iwai from comment #25)
> OK, then you're hitting multiple issues, as it seems.
> 
> The inconsistent value read from sysfs was addressed by my patch.  But, I
> suppose that the main reason of the non-functional backlight is that the
> driver misdetected the backlight control over aux.
> 
> I refreshed again the KMP with a hack patch to disable the aux support. 
> Please give it a try later again.  This will show a line "XXX
> ext_caps=0x..." in kernel log.

IT WORKED!!!!

Thank you for your time. I can now control the brightness with Fn Keys or the OS Slider in OpenSUSE. 

So the problem was with the aux detection. 

I know this is not a proper fix but it works. I hope you upstream this work to the mainline kernel or OpenSUSE patches??

OK, finally got some good news.

I'm rebuilding the KMP again with a patch to add a module option "aux_backlight" instead of blindly disabling the aux backlight.  So keep your working KMP for now, and check later the new KMP and test with
  amdgpu.aux_backlight=0
boot option.  This is no solution but an acceptable workaround, I suppose.

I'm going to submit two patches to upstream.

Oh, BTW, which value was shown in the "XXX ext_caps=..." line?

Created attachment 845785 [details]
Fix brightness sysfs value read for aux backlight

Created attachment 845786 [details]
Patch to add aux_backlight module option to amdgpu driver

(In reply to Takashi Iwai from comment #27)
> OK, finally got some good news.
> 
> I'm rebuilding the KMP again with a patch to add a module option
> "aux_backlight" instead of blindly disabling the aux backlight.  So keep
> your working KMP for now, and check later the new KMP and test with
>   amdgpu.aux_backlight=0
> boot option.  This is no solution but an acceptable workaround, I suppose.
> 
> I'm going to submit two patches to upstream.
> 

Yes it's okay but the official kernel maintainer and openSUSE is not going to accept this patch so I can see that the official support is very far away :P

> Oh, BTW, which value was shown in the "XXX ext_caps=..." line?

[    7.872674] amdgpu: XXX ext_caps=0xa7

Alex submitted the patches including my module parameter patch to the upstream amd-gfx ML, and now I updated amdgpu-dbg KMP based on those patches.  (And the debug print was dropped.)

Could you check it later together with the latest (matching) TW kernel?
Once after confirming it works for you, I'll merge those patches to TW kernel.

Even after merging TW, though, we'll still need to keep the upstream bug opened until more workarounds are implemented (e.g. DMI-based quirk entries).

(In reply to Takashi Iwai from comment #31)
> Alex submitted the patches including my module parameter patch to the
> upstream amd-gfx ML, and now I updated amdgpu-dbg KMP based on those
> patches.  (And the debug print was dropped.)
> 
> Could you check it later together with the latest (matching) TW kernel?
> Once after confirming it works for you, I'll merge those patches to TW
> kernel.
> 
> Even after merging TW, though, we'll still need to keep the upstream bug
> opened until more workarounds are implemented (e.g. DMI-based quirk entries).

Many thanks. With the kernel param amdgpu.backlight=0 the backlight brightness control works with the latest TW kernel and your package at the time of writing.

I wonder if we can get connected with any Lenovo or ASUS folks to find out what they did wrong? But I guess that's not gonna happen. Do they contribute anything open source in the first place?? Only time will tell :)

I backported the fixes to stable git branch for TW kernel now.

Unfortunately, we have no proper contact for both Lenovo and ASUS about the graphics.  Hopefully AMD people know anyone there...

(In reply to Takashi Iwai from comment #33)
> I backported the fixes to stable git branch for TW kernel now.
> 
> Unfortunately, we have no proper contact for both Lenovo and ASUS about the
> graphics.  Hopefully AMD people know anyone there...

I see the patches landed in kernel, should we close the bug report ?

Currently it allows user a control via a module option, but it's merely a manual workaround.  It needs the automatic correct setup, ideally speaking.

(In reply to Takashi Iwai from comment #37)
> Currently it allows user a control via a module option, but it's merely a
> manual workaround.  It needs the automatic correct setup, ideally speaking.

Of course, but I seems this is the best we can do at this moment.

Since you mention to keep the upstream bug open at comment#31, so I suggest to close this bug report and wait for upstream to fix / provide more workarounds.

If the forced disablement of the aux channel brightness is the only way, we can build up a quirk list based on DMI or such and let the driver automatically choose the right mode.  Such an implementation is trivial, but the primary question is what's the best way to detect that.  The quirk table is the last resort if no other generic probe doesn't work.

Seizing the opportunity:

Is there a way to see if this fix is going to be part of the KOTD? I'm in the same boat as OP, and I love to make use of the fix :-)

As I'm on Leap 15.2 I could also raise a separate bug against Leap 15.2 if you guys would prefer this (maybe for tracking purposes).

The amdgpu.backlight module option was already merged in the upstream, so TW should have a workaround (passing amdgpu.backlight=0 boot option).  This was also already merged in SLE15-SP3 / Leap 15.3 kernel, too.  But I don't think we'd fix this for Leap 15.2.

The root cause of the problem hasn't been figured out yet.  My bet is that it's a BIOS bug, and more proper workarounds are needed in AMDGPU driver side, but this has to be sorted out in the upstream development.  Feel free to join to the upstream gitlab Issues.

(In reply to Takashi Iwai from comment #42)
> The amdgpu.backlight module option was already merged in the upstream, so TW
> should have a workaround (passing amdgpu.backlight=0 boot option).  This was
> also already merged in SLE15-SP3 / Leap 15.3 kernel, too.  But I don't think
> we'd fix this for Leap 15.2.
> 
> The root cause of the problem hasn't been figured out yet.  My bet is that
> it's a BIOS bug, and more proper workarounds are needed in AMDGPU driver
> side, but this has to be sorted out in the upstream development.  Feel free
> to join to the upstream gitlab Issues.

It seems that without the amdgpu.backlight=0 kernel parameter the brightness control is working in hybrid mode. I don't know what fixed it maybe this https://gitlab.freedesktop.org/agd5f/linux/-/commit/f2ad3accefc63e72e9932e141c21875cc04beec8 commit.

But the brightness control seems to work good now in Linux 5.14.14 in TW.

Thanks for the updates.  The commit mentioned above is also included in SLE15-SP3 kernel, so hopefully everything works now.  Let's close for now.

SUSE-SU-2021:3675-1: An update that solves 15 vulnerabilities and has 56 fixes is now available.

Category: security (important)
Bug References: 1065729,1085030,1089118,1094840,1133021,1152472,1152489,1154353,1156395,1157177,1167773,1172073,1173604,1176447,1176774,1176914,1176940,1178134,1180100,1180749,1181147,1184673,1185762,1186063,1186109,1187167,1188563,1188601,1189841,1190006,1190067,1190349,1190351,1190479,1190620,1190642,1190795,1190801,1190941,1191229,1191240,1191241,1191315,1191317,1191349,1191384,1191449,1191450,1191451,1191452,1191455,1191456,1191628,1191645,1191663,1191731,1191800,1191851,1191867,1191934,1191958,1191980,1192040,1192041,1192074,1192107,1192145,1192229,1192267,1192288,1192549
CVE References: CVE-2021-33033,CVE-2021-34866,CVE-2021-3542,CVE-2021-3655,CVE-2021-3715,CVE-2021-37159,CVE-2021-3760,CVE-2021-3772,CVE-2021-3896,CVE-2021-41864,CVE-2021-42008,CVE-2021-42252,CVE-2021-42739,CVE-2021-43056,CVE-2021-43389
JIRA References: 
Sources used:
SUSE MicroOS 5.1 (src):    kernel-default-5.3.18-59.34.1, kernel-default-base-5.3.18-59.34.1.18.21.1
SUSE Linux Enterprise Workstation Extension 15-SP3 (src):    kernel-default-5.3.18-59.34.1, kernel-preempt-5.3.18-59.34.1
SUSE Linux Enterprise Module for Live Patching 15-SP3 (src):    kernel-default-5.3.18-59.34.1, kernel-livepatch-SLE15-SP3_Update_9-1-7.3.1
SUSE Linux Enterprise Module for Legacy Software 15-SP3 (src):    kernel-default-5.3.18-59.34.1
SUSE Linux Enterprise Module for Development Tools 15-SP3 (src):    kernel-docs-5.3.18-59.34.1, kernel-obs-build-5.3.18-59.34.1, kernel-preempt-5.3.18-59.34.1, kernel-source-5.3.18-59.34.1, kernel-syms-5.3.18-59.34.1
SUSE Linux Enterprise Module for Basesystem 15-SP3 (src):    kernel-64kb-5.3.18-59.34.1, kernel-default-5.3.18-59.34.1, kernel-default-base-5.3.18-59.34.1.18.21.1, kernel-preempt-5.3.18-59.34.1, kernel-source-5.3.18-59.34.1, kernel-zfcpdump-5.3.18-59.34.1
SUSE Linux Enterprise High Availability 15-SP3 (src):    kernel-default-5.3.18-59.34.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

openSUSE-SU-2021:3675-1: An update that solves 15 vulnerabilities and has 56 fixes is now available.

Category: security (important)
Bug References: 1065729,1085030,1089118,1094840,1133021,1152472,1152489,1154353,1156395,1157177,1167773,1172073,1173604,1176447,1176774,1176914,1176940,1178134,1180100,1180749,1181147,1184673,1185762,1186063,1186109,1187167,1188563,1188601,1189841,1190006,1190067,1190349,1190351,1190479,1190620,1190642,1190795,1190801,1190941,1191229,1191240,1191241,1191315,1191317,1191349,1191384,1191449,1191450,1191451,1191452,1191455,1191456,1191628,1191645,1191663,1191731,1191800,1191851,1191867,1191934,1191958,1191980,1192040,1192041,1192074,1192107,1192145,1192229,1192267,1192288,1192549
CVE References: CVE-2021-33033,CVE-2021-34866,CVE-2021-3542,CVE-2021-3655,CVE-2021-3715,CVE-2021-37159,CVE-2021-3760,CVE-2021-3772,CVE-2021-3896,CVE-2021-41864,CVE-2021-42008,CVE-2021-42252,CVE-2021-42739,CVE-2021-43056,CVE-2021-43389
JIRA References: 
Sources used:
openSUSE Leap 15.3 (src):    dtb-aarch64-5.3.18-59.34.1, kernel-64kb-5.3.18-59.34.1, kernel-debug-5.3.18-59.34.1, kernel-default-5.3.18-59.34.1, kernel-default-base-5.3.18-59.34.1.18.21.1, kernel-docs-5.3.18-59.34.1, kernel-kvmsmall-5.3.18-59.34.1, kernel-obs-build-5.3.18-59.34.1, kernel-obs-qa-5.3.18-59.34.1, kernel-preempt-5.3.18-59.34.1, kernel-source-5.3.18-59.34.1, kernel-syms-5.3.18-59.34.1, kernel-zfcpdump-5.3.18-59.34.1

SUSE-SU-2021:3806-1: An update that solves 6 vulnerabilities, contains one feature and has 35 fixes is now available.

Category: security (important)
Bug References: 1094840,1133021,1152489,1154353,1157177,1167773,1169263,1170269,1176940,1180749,1184924,1188601,1190523,1190795,1191628,1191790,1191851,1191958,1191961,1191980,1192045,1192217,1192229,1192267,1192273,1192288,1192328,1192375,1192473,1192549,1192718,1192740,1192745,1192750,1192753,1192758,1192781,1192802,1192896,1192906,1192918
CVE References: CVE-2021-0941,CVE-2021-20322,CVE-2021-31916,CVE-2021-34981,CVE-2021-37159,CVE-2021-43389
JIRA References: SLE-22573
Sources used:
SUSE Linux Enterprise Module for Public Cloud 15-SP3 (src):    kernel-azure-5.3.18-38.31.1, kernel-source-azure-5.3.18-38.31.1, kernel-syms-azure-5.3.18-38.31.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

openSUSE-SU-2021:3806-1: An update that solves 6 vulnerabilities, contains one feature and has 35 fixes is now available.

Category: security (important)
Bug References: 1094840,1133021,1152489,1154353,1157177,1167773,1169263,1170269,1176940,1180749,1184924,1188601,1190523,1190795,1191628,1191790,1191851,1191958,1191961,1191980,1192045,1192217,1192229,1192267,1192273,1192288,1192328,1192375,1192473,1192549,1192718,1192740,1192745,1192750,1192753,1192758,1192781,1192802,1192896,1192906,1192918
CVE References: CVE-2021-0941,CVE-2021-20322,CVE-2021-31916,CVE-2021-34981,CVE-2021-37159,CVE-2021-43389
JIRA References: SLE-22573
Sources used:
openSUSE Leap 15.3 (src):    kernel-azure-5.3.18-38.31.1, kernel-source-azure-5.3.18-38.31.1, kernel-syms-azure-5.3.18-38.31.1