Bugzilla – Bug 1180591
Display backlight stuck at 100%
Last modified: 2022-08-08 12:34:53 UTC
Created attachment 844855 [details] system information I have just upgraded my device to Tumbleweed and now backlight brightness is stuck at 100% with no way to change it. I have tried several methods, including xbacklight and Xfce settings. Backlight control used to work fine with Kernel 5.3 shipped by Leap. I found a recent report using similar hardware that could suggest a regression in the kernel: https://discuss.getsol.us/d/6039-brightness-control-not-working-on-apple-display-since-upgrade-to-510 I attached information about my system but please let me know what else I can provide.
Could you give the output of hwinfo and the output of dmesg? Also, try to adjust the brightness by manually writing to sysfs files /sys/class/backlight/*/brightness. The value ranges are found in /sys/class/backlight/*/max_brightness. e.g. on my laptop, I can change it like echo -n 200 > /sys/class/backlight/intel_backlight/brightness There might be multiple entries in /sys/class/backlight and you can try each of them. And, if it used to work with Leap kernel, could you try to install the latest Leap 15.2 kernel on the current system (with zypper install --oldpackage option), boot with it and test whether the brightness works? If Leap 15.2 kernel works, give again the output of hwinfo and dmesg from it.
Created attachment 844859 [details] dmesg Leap 15.2 kernel
Created attachment 844860 [details] dmesg TW kernel
Created attachment 844861 [details] hwinfo Leap 15.2 kernel
Created attachment 844862 [details] hwinfo TW kernel
(In reply to Takashi Iwai from comment #1) > Could you give the output of hwinfo and the output of dmesg? See attachemnts > Also, try to adjust the brightness by manually writing to sysfs files > /sys/class/backlight/*/brightness. The value ranges are found in > /sys/class/backlight/*/max_brightness. e.g. on my laptop, I can change it > like > echo -n 200 > /sys/class/backlight/intel_backlight/brightness > > There might be multiple entries in /sys/class/backlight and you can try each > of them. I tried and it did not help. > > And, if it used to work with Leap kernel, could you try to install the > latest Leap 15.2 kernel on the current system (with zypper install > --oldpackage option), boot with it and test whether the brightness works? > If Leap 15.2 kernel works, give again the output of hwinfo and dmesg from it. I still had the Leap 15.2 kernel installed and booting into allows me to change backlight. hwinfo and dmesg are attached. The issue only happens if I boot into the current TW kernel 5.10
Thanks. Judging from the given information, it's nouveau and the backlight is controlled solely via ACPI video driver. It's a bit surprising that the control doesn't take any effect in ACPI while it's exposed... Maybe narrowing the regression range might help. There are many kernel packages available in my OBS repo, e.g. home:tiwai:kernel:5.4, home:tiwai:kernel:5.5, etc. Could you try installing those old kernels one by one, and check which kernel started showing the bad behavior? Before testing that, it would be safer to increase the number of installable kernels in /etc/zypp/zypp.conf. Edit the file and add more entries in the line defining "multiversion.kernels".
(In reply to Takashi Iwai from comment #7) > Thanks. Judging from the given information, it's nouveau and the backlight > is controlled solely via ACPI video driver. It's a bit surprising that the > control doesn't take any effect in ACPI while it's exposed... > Actually I'm using the nvidia proprietary driver. Should I try nouveu drivers first?
Ah, that's what I wrongly remembered, sorry. But yes, testing with nouveau once would be interesting. This also allows testing with other older kernels more easily, too.
(In reply to Takashi Iwai from comment #9) > Ah, that's what I wrongly remembered, sorry. > > But yes, testing with nouveau once would be interesting. This also allows > testing with other older kernels more easily, too. Switching to nouveau made no difference. The last kernel allowing me to change display backlight is 5.7. So I guess the issue is introduced in kernel 5.8. I'm attaching the dmesg and hwinfo next.
Created attachment 844987 [details] hwinfo-kernel-5.7
Created attachment 844988 [details] dmesg-kernel-5.7
Created attachment 844989 [details] hwinfo-kernel-5.8
Created attachment 844990 [details] dmesg-kernel-5.8
Thanks. I checked briefly between v5.7 and v5.8, but there is no change in either driver/acpi/video_detect.c or drivers/acpi/acpi_video.c. So the ACPI code (in those areas) didn't change, and something else (also in ACPI) must be the cause of the regression. It's hard to tell for now. And, I looked at the backlight support on Apple machines and they are... well... messy. There is apple-gmux driver that supports things on some devices but it's only for ACPI APP000B, which isn't enabled on yours. At this moment, the best thing we can do is to git bisect. But of course it takes time (and patience).
(In reply to Takashi Iwai from comment #15) > Thanks. > > I checked briefly between v5.7 and v5.8, but there is no change in either > driver/acpi/video_detect.c or drivers/acpi/acpi_video.c. So the ACPI code > (in those areas) didn't change, and something else (also in ACPI) must be > the cause of the regression. It's hard to tell for now. > > And, I looked at the backlight support on Apple machines and they are... > well... messy. There is apple-gmux driver that supports things on some > devices but it's only for ACPI APP000B, which isn't enabled on yours. > > At this moment, the best thing we can do is to git bisect. But of course it > takes time (and patience). It's fine if it will take time, for the time being I'll look at the screen with sunglasses on :P. Thank you for looking into it.
Same problem for me. I'm on a livecd tumbelweed on a 27" late2013 Imac. The problem is the same, it is impossible for me to adjust the screen brightness using the slider in the kde menu, nor in the energy settings. Screen brightness is always at the absolute maximum. Setting the automatic brightness to 1 doesn't change anything. After adjust the brightness directly on /sys/class/backlight/acpi_video0 with the command : echo 7 > /sys/class/backlight/acpi_video0/brightness Nothing changes, even with other values. In the /sys/class/backlight folder, I only have acpi_video0. However, I have tried to change the settings at Grub startup : acpi_backlight=vendor, acpi_backlight=video,acpi_backlight=none, and acpi_backlight=native, but without success, the slider in the gnome menu disappears for (vendor, native and none). The problem is the same with nvidia or nouveau. If I go into sleep mode and then reactivate my machine, I can adjust the brightness again, but I can't do this from boot-up without going into sleep mode. The problem does not exist with opensuse leap 15.2 all works perfectly with a 5.3 kernel. To have a disk with Ubuntu 20.04, the problem is the same. With the 5.4 kernel, I can adjust the brightness, but with the HWE kernel update to version 5.8, I can't anymore. I think that the problem comes indeed from the kernel.
I confirm that putting the machine in sleep/suspend mode and resume allows me to adjust brightness.
Aha, that's interesting! You did suspend-to-RAM, resume and the brightness adjustment starts working?
yes suspend to ram and after resume the brightness bar starts working and so does the actual brightness level.
OK, then could you try to test with /sys/power/pm_test and see which stage it starts working? Namely, there are 5 stages of PM tests: freezer, devices, platform, processors and core. (Those are shown by "cat /sys/power/pm_test".) Writing the value to the sysfs selects the test stage. e.g. # echo -n freezer > /sys/power/pm_test then start the suspend test # echo -n mem > /sys/power/state It'll freeze the processes and resumes after 5 seconds. Check whether the brightness adjustment works after that. (Likely not after freezer.) Then try "devices" # echo -n devices > /sys/power/pm_test # echo -n mem > /sys/power/state follow "platform", "processors" and "core" until you get the brightness working. After testing, reset it by writing "none" # echo -n "none" > /sys/power/pm_test
With "core" "processors" "platform" "devices" "freezer" did not work. Setting to "none" did.
You mean that the PM test works (go blank or freeze for 5 seconds and resumes) but the brightness still doesn't work after that? If so, it's disappointing. It means that the function is enabled only when the machine really goes to sleep, so some device resume procedure alone doesn't help. Then it's really something to do with BIOS/ACPI, and that's hard to judge what really helps... BTW, the problem happens always, not only after the (warm) reboot, right?
(In reply to Takashi Iwai from comment #23) > You mean that the PM test works (go blank or freeze for 5 seconds and > resumes) but the brightness still doesn't work after that? Correct, PM test works but brighness is still stuck unless I run the test with the "none" parameter. In that case then brightness does work > > If so, it's disappointing. It means that the function is enabled only when > the machine really goes to sleep, so some device resume procedure alone > doesn't help. > Then it's really something to do with BIOS/ACPI, and that's hard to judge > what really helps... > > BTW, the problem happens always, not only after the (warm) reboot, right? Not sure what you mean here but problem is persistent. At each reboot the brightness is maxed to 100%
Same thing for me. one of the differences I noticed, in the initial startup, there is no mention of backlighting (dmesg) on the other hand, after a standby mode, the following appears: "video LNXVIDEO:00: Restoring backlight state" I don't know if this can help you. Is there a way to start this command after the initial boot to test if it changes anything?
(In reply to Maurizio Galli from comment #24) > > BTW, the problem happens always, not only after the (warm) reboot, right? > > Not sure what you mean here but problem is persistent. At each reboot the > brightness is maxed to 100% I meant whether the problem persists if you do cold boot (complete power off, then boot), too. I guess yes, but just to make clear. (In reply to LAURENT LE POITTEVIN from comment #25) > Same thing for me. > one of the differences I noticed, in the initial startup, there is no > mention of backlighting (dmesg) > on the other hand, after a standby mode, the following appears: > "video LNXVIDEO:00: Restoring backlight state" > I don't know if this can help you. > Is there a way to start this command after the initial boot to test if it > changes anything? This is from the resume callback of ACPI video driver, and that's the very same function (executing _BCM ACPI method) as the normal sysfs backlight change. So it implies that BIOS ignores this method execution by some reason unless you do suspend/resume.
Ok thanks for the info. I was able to find out about it and start to understand a little bit how it works. I followed the test list on this page and I was able to make some changes. Notably, a start at the brightness I set just before rebooting. But the brightness slider remains inoperative. I could visualize a change of brightness during the boot with the following parameters in the boot line of the grub : _video.use_bios_initial_backlight=0 (the parameter appears as unknow in dmesg but the brightness is set to the requested value, the sliders is inoperative) _ acpi_osi= (the brightness is set to the requested value, the sliders are inoperative) video.use_bios_initial_backlight=1 (the parameter appears as unknow in dmesg but the brightness is set to the requested value, the sliders are inoperative) _ acpi.brightness_switch_enabled=0 (brightness is set to the requested value, sliders are inoperative). I attach the different files made during the test in case.
Created attachment 846533 [details] https://wiki.ubuntu.com/Kernel/Debugging/Backlight - acpidump https://wiki.ubuntu.com/Kernel/Debugging/Backlight acpidump report
Created attachment 846534 [details] https://wiki.ubuntu.com/Kernel/Debugging/Backlight - dmidecode https://wiki.ubuntu.com/Kernel/Debugging/Backlight dmidecode report
Created attachment 846535 [details] https://wiki.ubuntu.com/Kernel/Debugging/Backlight fwts https://wiki.ubuntu.com/Kernel/Debugging/Backlight fwts report
Created attachment 846536 [details] https://wiki.ubuntu.com/Kernel/Debugging/Backlight proc-acpi https://wiki.ubuntu.com/Kernel/Debugging/Backlight proc-acpi report
Created attachment 846537 [details] https://wiki.ubuntu.com/Kernel/Debugging/Backlight sys-class-backlight https://wiki.ubuntu.com/Kernel/Debugging/Backlight sys-class-backlight
Created attachment 846538 [details] https://wiki.ubuntu.com/Kernel/Debugging/Backlight result test fwts https://wiki.ubuntu.com/Kernel/Debugging/Backlight result test fwts
It has been a while. There is a much newer kernel version in TW now. Does the issue still persist with that? It could be the case, since it looks like a problem with BIOS or ACPI.
(In reply to Miroslav Beneš from comment #34) > It has been a while. There is a much newer kernel version in TW now. Does > the issue still persist with that? It could be the case, since it looks like > a problem with BIOS or ACPI. In fact I have just recently also started seeing this issue on Tumbleweed It was still working about a week ago for me and now neither the xfce4-power-manager nor xbacklight are able to change screen brightness > # xbacklight -set 100 > RANDR Query Version returned error -1 Using the method of writing to /sys with echo does work for me: > echo 378 > /sys/devices/pci0000\:00/0000\:00\:02.0/drm/card1/card1-eDP-1/intel_backlight/brightness
(In reply to Marcel Kuehlhorn from comment #35) > (In reply to Miroslav Beneš from comment #34) > > It has been a while. There is a much newer kernel version in TW now. Does > > the issue still persist with that? It could be the case, since it looks like > > a problem with BIOS or ACPI. > > In fact I have just recently also started seeing this issue on Tumbleweed > > It was still working about a week ago for me and now neither the > xfce4-power-manager nor xbacklight are able to change screen brightness That's weird. xfce4-power-manager should access directly /sys/class/backlight stuff (via xfpm-power-backlight-helper), at least. If changing the sysfs entry directly works, it should work, too. There seems to have had some breakage and got fixed in TW about xfce4-power-manager (bsc#1202125). Could you recheck? > > # xbacklight -set 100 > > RANDR Query Version returned error -1 If any, this must be an issue in user-space, not kernel. > Using the method of writing to /sys with echo does work for me: > > echo 378 > /sys/devices/pci0000\:00/0000\:00\:02.0/drm/card1/card1-eDP-1/intel_backlight/brightness
(In reply to Takashi Iwai from comment #36) > There seems to have had some breakage and got fixed in TW about > xfce4-power-manager (bsc#1202125). Could you recheck? > Thanks for the pointer to the other ticket It seems that somehow pkexec was not present and was pulled in as weak dependency of gparted and gvfs-backends in todays update and the brightness control works again I'll make a SR to xfpm to add it as requirement