Bug 203905 - amdgpu:actual_brightness has unreal/wrong value
Summary: amdgpu:actual_brightness has unreal/wrong value
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - non Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_video-dri
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-15 20:02 UTC by Bjoern Franke
Modified: 2024-10-22 11:41 UTC (History)
25 users (show)

See Also:
Kernel Version: 5.1.9
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg (81.79 KB, text/plain)
2019-06-17 10:48 UTC, Bjoern Franke
Details
Dmesg 8-9-2020 (84.74 KB, text/plain)
2020-09-08 01:00 UTC, John Shand
Details
Journalctl 8-9-2020 (340.21 KB, text/plain)
2020-09-08 01:03 UTC, John Shand
Details

Description Bjoern Franke 2019-06-15 20:02:00 UTC
Radeon R5/R6/R7 Graphics in a Thinkpad A275 has wrong values on actual_brightness of amdgpu_bl0. While max_brightness is 255 and it can be set to 255, actual_brightness reports a 5 digit number like 12470. As a result, tools which want to change the brightness related to actual_brightness fail, as brightness does not accept any 5 digit number,
Comment 1 Michel Dänzer 2019-06-17 09:44:51 UTC
Please attach the output of dmesg.
Comment 2 Bjoern Franke 2019-06-17 10:48:16 UTC
Created attachment 283299 [details]
dmesg
Comment 3 Lukáš Krejčí 2019-09-26 21:07:32 UTC
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.
Comment 4 Sandor Ecker 2020-02-05 05:34:44 UTC
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
Comment 5 Sandor Ecker 2020-02-05 05:52:30 UTC
Would it be possible to set max_brightness to 2^16-1 ?
Comment 6 Sandor Ecker 2020-02-09 13:33:15 UTC
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?
Comment 7 Sandor Ecker 2020-02-10 19:16:23 UTC
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...?
Comment 8 Flo Bock 2020-07-30 06:15:51 UTC
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
Comment 9 Kunal Bhat 2020-08-01 12:04:53 UTC
(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
Comment 10 Alexander Monakov 2020-08-03 20:13:43 UTC
Proposed patch: https://lore.kernel.org/lkml/20200803200218.2167-1-amonakov@ispras.ru/
Comment 11 Alexander Monakov 2020-08-04 20:15:24 UTC
v2 patch: https://lore.kernel.org/lkml/20200804201313.6464-1-amonakov@ispras.ru/
Comment 12 rugk 2020-08-17 09:46:21 UTC
(Backlink only) Same issue reported on https://discussion.fedoraproject.org/t/amd-amdgpu-bl0-backlight-not-restored/20445?u=rugk
Comment 13 shanmukhateja@gmail.com 2020-08-31 10:46:46 UTC
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
Comment 14 Xia Mu 2020-09-01 19:07:34 UTC
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.
Comment 15 John Shand 2020-09-08 00:59:17 UTC
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??
Comment 16 John Shand 2020-09-08 01:00:26 UTC
Created attachment 292417 [details]
Dmesg 8-9-2020
Comment 17 John Shand 2020-09-08 01:03:00 UTC
Created attachment 292419 [details]
Journalctl 8-9-2020
Comment 18 Germán Ríos González 2020-11-23 21:02:48 UTC
(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
Comment 19 kurmikon 2020-12-07 10:17:33 UTC
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
Comment 20 Antony J.R 2021-02-02 14:06:50 UTC
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.
Comment 21 Paulo Nascimento 2021-02-07 22:17:49 UTC
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
Comment 22 Antony J.R 2021-02-08 20:47:44 UTC
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.
Comment 23 m11.1l1.f64 2021-02-17 17:24:20 UTC
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
Comment 25 m11.1l1.f64 2021-03-15 10:58:03 UTC
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 :)_
Comment 26 Paulo Nascimento 2021-03-25 13:58:33 UTC
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?
Comment 27 kurmikon 2021-03-25 14:03:53 UTC
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.
Comment 28 Antony J.R 2021-03-27 08:45:04 UTC
(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
Comment 29 Filip Hejsek 2021-05-06 10:12:10 UTC
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).
Comment 30 Paulo Nascimento 2021-05-06 11:50:54 UTC
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.
Comment 31 Paulo Nascimento 2021-05-06 11:56:30 UTC
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.
Comment 32 Filip Hejsek 2021-05-06 13:28:34 UTC
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).
Comment 33 Filip Hejsek 2021-05-06 14:20:16 UTC
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)

Note You need to log in before you can comment on or make changes to this bug.