Bug 203905
Summary: | amdgpu:actual_brightness has unreal/wrong value | ||
---|---|---|---|
Product: | Drivers | Reporter: | Bjoern Franke (bjo) |
Component: | Video(DRI - non Intel) | Assignee: | drivers_video-dri |
Status: | NEW --- | ||
Severity: | normal | CC: | alpha-shadows, amonakov, antonyjr000, com-kernel, esanya, filip.hejsek, flo, german.rios.gonzalez, hujq, jml86khakons, jshand2013, kunal.bhat2001, kurmikon, lskrejci, m11.1l1.f64, mascot26, navarroaxel, nicholas.kazlauskas, onehalf3544, paulo.ulusu, savelov, shanmukhateja, timothy.ty.lee, whenov, yar-demyan |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 5.1.9 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
dmesg
Dmesg 8-9-2020 Journalctl 8-9-2020 |
Description
Bjoern Franke
2019-06-15 20:02:00 UTC
Please attach the output of dmesg. Created attachment 283299 [details]
dmesg
Commit 262485a50fd4 ("drm/amd/display: Expand dc to use 16.16 bit backlight") changed the value that is returned for `actual_brightness`: -static unsigned int dce_abm_get_current_backlight_8_bit(struct abm *abm) +static unsigned int dce_abm_get_current_backlight(struct abm *abm) { struct dce_abm *abm_dce = TO_DCE_ABM(abm); unsigned int backlight = REG_READ(BL1_PWM_CURRENT_ABM_LEVEL); - return (backlight >> 8); + /* return backlight in hardware format which is unsigned 17 bits, with + * 1 bit integer and 16 bit fractional + */ + return backlight; } I could not find anything official about the range of `actual_brightness`, only the following blog says that is has to be in range of `brightness`: https://nikula.org/~jani/backlight/#index3h3 I guess amdgpu_dm_backlight_get_brightness() could be changed to bring the `actual_brightness` value in range of `brightness` again since it returns the value of `brightness` in the error path anyway. Hi, I have the same Issue. I have written a bug report to this: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu/+bug/1861925 Maybe that is not the correct place... Is any news regarding the problem? Thx, Regards, Sandor Would it be possible to set max_brightness to 2^16-1 ? So it seems that the 16 bit actual_brightness is not a bug, but a feature... :) https://github.com/torvalds/linux/commit/262485a50fd4532a8d71165190adc7a0a19bcc9e#diff-b496037255b7766a782d3f3711b50db8 So my question now: -why are the max_brightness and brightness values in 8bit range? I have upgraded to 5.6.rc1: uname -a Linux Aspire-A315-41 5.6.0-050600rc1-generic #202002092032 SMP Mon Feb 10 01:36:50 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux I have seen that the code has log messages like: DC_LOG_BACKLIGHT("New Backlight level: %d (0x%X)\n", backlight_pwm_u16_16, backlight_pwm_u16_16); I have set the kernel log by echo "8" > /proc/sys/kernel/printk cat /proc/sys/kernel/printk 8 4 1 7 but I can't see any logmessage with "New Backlight" in the output of the commands: grep -i "new backli" /var/log/* dmesg |grep -i "back" Maybe it does not reach that line of code? Or the log should be visible somewhere else... ? Can somebody help...? With recent systemd changes, the 16 bit values in actual_brightness break saving and restoring the backlight values using AMDGPU. According to a closed issue on Github, Lennart Poettering sees this as a kernel issue[1]. Is there any good reason for actual_brightness to be 16bit, whereas both max_brightness and brightness are 8bit? [1]: https://github.com/systemd/systemd/issues/16600 (In reply to Flo Bock from comment #8) > With recent systemd changes, the 16 bit values in actual_brightness break > saving and restoring the backlight values using AMDGPU. According to a > closed issue on Github, Lennart Poettering sees this as a kernel issue[1]. > Is there any good reason for actual_brightness to be 16bit, whereas both > max_brightness and brightness are 8bit? > > [1]: https://github.com/systemd/systemd/issues/16600 I believe it's there to provide a higher range of precision for the backlight. Not sure why they never extended the range for max_brightness. The systemd devs are adamant that this is a driver issue, and aren't ready to implement a work around for it. I believe this is the open issue with the discussions right now: https://github.com/systemd/systemd/issues/16630 (Backlink only) Same issue reported on https://discussion.fedoraproject.org/t/amd-amdgpu-bl0-backlight-not-restored/20445?u=rugk I have built a workaround for this issue by forking systemd-backlight for the time-being. It has been tested on my ASUS TUF FX505DT with Ryzen 3550H. https://github.com/shanmukhateja/systemd/tree/fix-amdgpu-backlight The bug should be fixed in 5.9.0-0.rc3. I tested it on my laptop with AMD Ryzen 7 PRO 4750U CPU with Renoir GPU. i have had this problem as well. was recently working well with kernel 5.8.7. i then install ucode-amd and then grub-mkconfig -o /boot/grub/grub.cfg to set the changes. grub automatically made the new code image work with initramfs and then, backlight went back to about 20% or 255. would this have anything to do with amd's ucode image?? Created attachment 292417 [details]
Dmesg 8-9-2020
Created attachment 292419 [details]
Journalctl 8-9-2020
(In reply to Xia Mu from comment #14) > The bug should be fixed in 5.9.0-0.rc3. I tested it on my laptop with AMD > Ryzen 7 PRO 4750U CPU with Renoir GPU. I'm actually using 5.9.9-200.fc33.x86_64 and the problem it's still there I confirm that the bug is not fixed in 5.9.12. https://github.com/systemd/systemd/issues/17826 As Poettering pointed out, actual_brightness is read-only and reports the brightness currently in effect, while brightness is writable and reports the value set by userspace. Not only the actual brightness is in a different range that breaks systemd backlight restoring service at startup, but on my device its value is also fixed on the same value while it should reflect the correct level on brightness changes. Brightness at the maximum: /sys/class/backlight/amdgpu_bl0/actual_brightness > 249 /sys/class/backlight/amdgpu_bl0/brightness > 255 /sys/class/backlight/amdgpu_bl0/max_brightness > 255 Brightness at the minimum: /sys/class/backlight/amdgpu_bl0/actual_brightness > 249 /sys/class/backlight/amdgpu_bl0/brightness > 2 /sys/class/backlight/amdgpu_bl0/max_brightness > 255 I can confirm that the bug is still not fixed even in 5.11-rc6 (the latest kernel at the time of writing). I can't control brightness also. I have a AMD Ryzen 7 4800H APU which has Renoir Graphics. The brightness control only works with Fedora Workstation 32 with Linux Kernel 5.6.6 but with 5.11-rc6 brightness control does not work at all. I confirm that the bug is not fixed in kenel 5.11-rc3 max brightness: [pn@pn-legion backlight]$ cat /sys/class/backlight/amdgpu_bl1/actual_brightness 311 [pn@pn-legion backlight]$ cat /sys/class/backlight/amdgpu_bl1/brightness 255 [pn@pn-legion backlight]$ cat /sys/class/backlight/amdgpu_bl1/max_brightness 255 min brightness: [pn@pn-legion backlight]$ cat /sys/class/backlight/amdgpu_bl1/actual_brightness 311 [pn@pn-legion backlight]$ cat /sys/class/backlight/amdgpu_bl1/brightness 0 [pn@pn-legion backlight]$ cat /sys/class/backlight/amdgpu_bl1/max_brightness 255 My laptop has an amd ryzen 5 4600h with renoir igpu and nvidia dgpu. Tests are done with renoir igpu: [pn@pn-legion backlight]$ inxi -G Graphics: Device-1: NVIDIA TU116M [GeForce GTX 1660 Ti Mobile] driver: nouveau v: kernel Device-2: Advanced Micro Devices [AMD/ATI] Renoir driver: amdgpu v: kernel Device-3: Chicony Integrated Camera type: USB driver: uvcvideo Display: x11 server: X.Org 1.20.10 driver: loaded: amdgpu,ati,modesetting,nouveau resolution: 1920x1080~120Hz OpenGL: renderer: AMD RENOIR (DRM 3.40.0 5.11.0-1-MANJARO LLVM 11.0.1) v: 4.6 Mesa 20.3.3 Created attachment 295123 [details] attachment-28816-0.html A workaround for this is done by the OpenSUSE folks, Please see https://bugzilla.opensuse.org/show_bug.cgi?id=1180749 The only distro which fixes this is OpenSUSE. This is because there is a bug in the mainline kernel and kernel devs are not responding to us for some reason(maybe file a new issue???). The problem is that the kernel uses aux for backlight control but our systems don't support backlight control via aux. So disabling aux completely from amdgpu kernel module can give us backlight control for the iGPU. I've tested it and it works just find. Regards, Antony J.R On Mon, Feb 8, 2021 at 3:47 AM <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=203905 > > Paulo Nascimento (paulo.ulusu@googlemail.com) changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| | > paulo.ulusu@googlemail.com > > --- Comment #21 from Paulo Nascimento (paulo.ulusu@googlemail.com) --- > I confirm that the bug is not fixed in kenel 5.11-rc3 > > max brightness: > [pn@pn-legion backlight]$ cat > /sys/class/backlight/amdgpu_bl1/actual_brightness > 311 > [pn@pn-legion backlight]$ cat /sys/class/backlight/amdgpu_bl1/brightness > 255 > [pn@pn-legion backlight]$ cat > /sys/class/backlight/amdgpu_bl1/max_brightness > 255 > > min brightness: > [pn@pn-legion backlight]$ cat > /sys/class/backlight/amdgpu_bl1/actual_brightness > 311 > [pn@pn-legion backlight]$ cat /sys/class/backlight/amdgpu_bl1/brightness > 0 > [pn@pn-legion backlight]$ cat > /sys/class/backlight/amdgpu_bl1/max_brightness > 255 > > My laptop has an amd ryzen 5 4600h with renoir igpu and nvidia dgpu. > Tests are done with renoir igpu: > > [pn@pn-legion backlight]$ inxi -G > Graphics: Device-1: NVIDIA TU116M [GeForce GTX 1660 Ti Mobile] driver: > nouveau > v: kernel > Device-2: Advanced Micro Devices [AMD/ATI] Renoir driver: > amdgpu v: > kernel > Device-3: Chicony Integrated Camera type: USB driver: uvcvideo > Display: x11 server: X.Org 1.20.10 driver: loaded: > amdgpu,ati,modesetting,nouveau resolution: 1920x1080~120Hz > OpenGL: renderer: AMD RENOIR (DRM 3.40.0 5.11.0-1-MANJARO LLVM > 11.0.1) v: 4.6 Mesa 20.3.3 > > -- > You may reply to this email to add a comment. > > You are receiving this mail because: > You are on the CC list for the bug. There's a workaround here I hope it helps :) simply write this into `/etc/systemd/system/backlight-fix.service`: ``` [Unit] Description=Dummy service for attempting to start the problematic amdgpu_bl0 service [Service] Type=simple ExecStart=systemctl start systemd-backlight@backlight:amdgpu_bl0 [Install] WantedBy=multi-user.target ``` And then `sudo systemctl enable --now backlight-fix.service` Bingo!! The problem is gone Related to the previous post: https://www.linux.org/threads/failed-to-start-load-save-screen-backlight-brightness-of-amdgpu_bl1.31998/#post-113058 I found another workaround and it's easier than EVER and it's done via mkinitcpio😁 First, what's mkinitcpio(https://wiki.archlinux.org/index.php/Mkinitcpio)? The initial ramdisk is in essence a very small environment (early userspace) which loads various kernel modules and sets up necessary things before handing over control to init. This makes it possible to have, for example, encrypted root file systems and root file systems on a software RAID array. mkinitcpio allows for easy extension with custom hooks, has autodetection at runtime, and many other features. So go ahead and edit with `sudo nano /etc/mkinitcpio.conf` Then add the "amdgpu" in the modules section like this: `MODULES=(amdgpu)` After that, simply run `sudo mkinitcpio -P` so that it regenerates mkinitcpio for all kernels This solved my issue, I hope it works for others too :)_ laptop: Lenovo Legion 5, amd ryzen 5 4600h Graphics: Device-1: NVIDIA TU116M [GeForce GTX 1660 Ti Mobile] driver: nouveau Device-2: Advanced Micro Devices [AMD/ATI] Renoir driver: amdgpu Kernel 5.11.6-1 Manjaro 21.1 I have tried all suggested workarounds: - systemctl start systemd-backlight@backlight:amdgpu_bl0 - mkinitcpio with MODULES=(amdgpu) - acpi_backlight=vendor - acpi_backlight=video - /usr/lib/systemd/systemd-backlight save backlight:amdgpu_bl0 /usr/lib/systemd/systemd-backlight load backlight:amdgpu_bl0 Even echo 10 >/sys/class/backlight/amdgpu_bl0/brightness doesn't change the brightness. Any suggestions? For me the only workaround to avoid this bug is disabling systemd backlight restoration. Then use brillo and enable a specific service to restore the brightness at startup. (In reply to Paulo Nascimento from comment #26) > laptop: Lenovo Legion 5, amd ryzen 5 4600h > Graphics: Device-1: NVIDIA TU116M [GeForce GTX 1660 Ti Mobile] driver: > nouveau > Device-2: Advanced Micro Devices [AMD/ATI] Renoir driver: amdgpu > Kernel 5.11.6-1 > Manjaro 21.1 > > I have tried all suggested workarounds: > - systemctl start systemd-backlight@backlight:amdgpu_bl0 > > - mkinitcpio with MODULES=(amdgpu) > > - acpi_backlight=vendor > > - acpi_backlight=video > > - /usr/lib/systemd/systemd-backlight save backlight:amdgpu_bl0 > /usr/lib/systemd/systemd-backlight load backlight:amdgpu_bl0 > > Even echo 10 >/sys/class/backlight/amdgpu_bl0/brightness doesn't change the > brightness. > > Any suggestions? Please read the entire thread here -> https://bugzilla.opensuse.org/show_bug.cgi?id=1180749 All the workarounds posted here are for a different bug: https://bugzilla.kernel.org/show_bug.cgi?id=210263 There are three different problems: - setting brightness doesn't work before showing something on display (the bug linked above) - actual_brightness has wrong range (this bug) - kernel uses aux for backlight control on systems that don't support it For the third problem, there is a patch in https://bugzilla.opensuse.org/show_bug.cgi?id=1180749, and it seems to be merged already. However, because there is no way yet to detect that aux backlight doesn't work, the workaround has to be enabled with amdgpu.aux_backlight=0 (assuming you have a kernel with the patch). laptop: Lenovo Legion 5, amd ryzen 5 4600h Graphics: Device-1: NVIDIA TU116M [GeForce GTX 1660 Ti Mobile] driver: nouveau Device-2: Advanced Micro Devices [AMD/ATI] Renoir driver: amdgpu Kernel: 5.12.0-1-MANJARO x86_64 I have loaded kernel 5.12 and enabled the patch with amdgpu.backlight=0. The brightness controls Fn+F5/F6 works as well as the controls in KDE panel. There are still the error messages at boot and shutdown though. Error messages are: Mai 03 23:01:37 pn-legion systemd-backlight[861]: Failed to get backlight or LED device 'backlight:acpi_video1': No such device Mai 03 23:01:37 pn-legion systemd-backlight[862]: amdgpu_bl1: Failed to write system 'brightness' attribute: No such device or address Mai 03 23:01:37 pn-legion systemd[1]: Failed to start Load/Save Screen Backlight Brightness of backlight:acpi_video1. I think it has to do with the NVIDIA device. The acpi_video error seems to be https://github.com/systemd/systemd/issues/15329 - first the ACPI driver creates acpi_video1 device, then amdgpu removes it in favor of amdgpu_bl1, but systemd still tries to set brightness on the removed device (which fails). You can remove the error by masking `systemd-backlight@backlight:acpi_video1.service`. The amdgpu_bl1 error is probably the bug i linked earlier - https://bugzilla.kernel.org/show_bug.cgi?id=210263. Do you have silent boot? If yes, you need to print something to console before setting backlight during boot. You can use the workaround i posted here: https://bbs.archlinux.org/viewtopic.php?pid=1971198#p1971198. If you use my workaround, make sure to remove other workarounds you may have applied for that error (like another service that runs systemctl start systemd-backlight@backlight:amdgpu_bl0). Forgot to mention: since your AMD GPU has number 1 (not 0), you need to replace acpi_video0 with acpi_video1 in my workaround. (To others: sorry for the email spam) |