Bug 11769
Summary: | LCD brightness constantly set back to 100% - Gateway MX6961 laptop w/ Intel GMA950 graphics | ||
---|---|---|---|
Product: | ACPI | Reporter: | Marc St-Laurent (mstlaurent) |
Component: | Power-Video | Assignee: | Zhang Rui (rui.zhang) |
Status: | REJECTED INVALID | ||
Severity: | normal | CC: | acpi-bugzilla, ascii79, zhenyu.z.wang |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.27 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: |
Kernel 2.6.27 .config file
The output of acpidump debug patch debug patch Dmesg for patch from comment #19 commands and output for test in comment 22 Output of "xrandr --verbose" Various commands that show the brightness file levels w/ 2.6.27.5 Tests with 2.6.28-rc6 from git |
Description
Marc St-Laurent
2008-10-15 12:12:44 UTC
Created attachment 18327 [details]
Kernel 2.6.27 .config file
Reverting the following patch has made the brightness changes go away: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c2c789057f075022658b38b498755c29c1ba8055 However, it also makes /sys/class/backlight disappear, and /proc/acpi/video/VGA/LCD/brightness says that the current level is 0%, when it is 62%. Will you please attach the output of acpidump? Thanks. Hi, Marc How about this issue if you change the brightness by using the "/sys/class/backlight/acpi_vide*/brightness"? From the description it seems that there is no _BQC ACPI object. But the acpi video backlight is still registered and the brightness will be set to the maxmium in the boot phase. After the system is booted, how to change the brightness depends on the user input or ACPI event. Will you please kill the process which is using the "/proc/acpi/event" and see whether the brightness is still constantly set to 100%? Thanks. Please use the command of "lsof /proc/acpi/event" to get the process which is using the /proc/acpi/event. Thanks. Created attachment 18385 [details]
The output of acpidump
Hello, I can confirm that _BQC is always = 0. I added some printk() calls to a test kernel last week. The process that reads /proc/acpi/event is acpid. I rebooted with all daemons disabled, and it made no difference. There are no video related actions in my acpid configuration. It is only used to suspend the laptop. After booting, the value of /sys/class/backlight/*/brightness is 7 (maximum), and the value in /proc/acpi/video/VGA/LCD/brightness is 100. Using the brightness functions keys, the brightness of the monitor obviously changes, but the values in those 2 files remain at maximum. If I echo a different value into either of those files, both the brightness and the value change, as they should. Switching to console or returning form xorg screen blank set the brightness to maximum, but the values in the 2 files remain unchanged. Example: 1) After boot, screen is at 100% 2) I do "echo 62 > /proc/acpi/.../brightness". Screen brightness goes down, and the brightness file contains the correct value. 3) I switch to console using Ctrl+Alt+F1. The brightness goes to 100%, but the /proc/acpi... file still says 62%. I hope I've given you all the info you need. Thanks for looking into this. Marc did you try latest intel x-windows gfx driver? I have intel driver 2.3.2, but the problems occur outside of xorg, too. I think that in the absence of the _BQC object, if there is no way of reading the current brightness level, then it should be left unchanged and unititialized. Setting it to any value would only be a (wrong) guess. Then if the user specifically requests a brightness change with the Fn keys, set it to maximum (or some value), then let the user adjust the brightness himself. This would be very close to the former behavior from 2.6.26, I believe. What do you think? I upgraded xf86-video-intel to version 2.5.0, and there is no change. Hi, Marc Will you please do the test as mentioned in comment #7 on the 2.6.26.6 kernel and confirm whether the brightness returned by /proc/acpi/. is consistent with the real brightness? From the test in comment #7 it seems that the brightness is changed by BIOS after pressing CTRL+AL+F1. As there is no _BQC object, the /proc/acpi/ or /sys/class/backlight/* can't reflect the current brightness. thanks. Here is my test with 2.6.26.6 1) Before rebooting into 2.6.26.6, I set the brightness to 62%, my preferred level. 2) After booting into 2.6.26.6, the brightness level does NOT change. /sys/class/backlight is an empty directory, and /proc/acpi/video/VGA/LCD/brightness says the current level is 0%. There is an inconsistency. 3) Switching between xorg and console does not change the /proc/.. file, nor the brightness level. Everything stays the same. 4) If I echo a value into /proc/acpi.., the brightness will change accordingly, and the file will now contain the correct value. 5) After echoing the value into /proc/acpi.., switching from xorg to console does not change the brightness nor the /proc/acpi.. file. They are still at the correct values. (In reply to comment #7) > After booting, the value of /sys/class/backlight/*/brightness is 7 (maximum), > and the value in /proc/acpi/video/VGA/LCD/brightness is 100. Using the > brightness functions keys, the brightness of the monitor obviously changes, > but > the values in those 2 files remain at maximum. test1: kill acpid and run "cat /proc/acpi/event", what do you get when pressing the hotkey? test2: "echo 0 > /sys/module/video/parameters/brightness_switch_enabled" can you change the backlight via hotkey any more? Note that the BIOS is tricky. Method (LBCM, 1, NotSerialized) { If (\_OSI ("Windows 2006")) { ... } } the method for backlight control only works on windows Vista. i.e. any previous windows releases don't use this method for backlight control. what if you boot with acpi_osi="!Windows 2006"? PS, in this case, both the proc and sys backlight I/F may not work for you. Test 1 done with 2.6.27.3 and acpid killed: [root@~] cat /proc/acpi/event video DD04 00000086 00000000 video DD04 00000086 00000000 video DD04 00000087 00000000 video DD04 00000087 00000000 Test 2: No I can't change the brightness with the hotkeys after running "echo 0 > /sys/module/video/parameters/brightness_switch_enabled" But echoing a value into /sys/class/backlight/... still works. I will reboot with the acpi_osi argument and give you the results in a few minutes. I have now booted with the acpi_osi argument. - At boot time, the brightness level did not get set to 100%. It remained at the level I want (62%). - The brightness files in /sys and /proc both exist, they report maximum brightness. - Switching to console and back to xorg makes no difference in brightness. - Writing different values into the brightness files makes no change either. - Echoing a value in the /sys brightness file does not change the /proc brightness file. They are in an inconsistent state. - Using the hotkeys, the actual brightness changes, but the /sys and /proc files do not get updated. Hi, Marc Will you please apply the patch in http://bugzilla.kernel.org/show_bug.cgi?id=10206#C13 on the 2.6.26.6 kernel and see whether the issue still exists? thanks. Hello, Sorry for taking so long. I discovered that I cannot easily revert to an older kernel, so I had to install a 2nd copy of linux on a temporary partition. Anyway, here are the results with kernel 2.6.26.6, and the patch in comment 16. - At boot time, when video.ko gets loaded, the brightness goes to 100%. /sys/class/backlight gets created properly. All brightness files say 100%. - Echoing a value in /proc/acpi... changes that file and the actual brightness, but /sys/class.. never gets updated. It remains inconsistent throughout the whole test. - Switching from xorg to console sets the actual brightness to 100%, but the brightness files remain as they were before the switch. Created attachment 18795 [details]
debug patch
please apply this patch on the latest kernel source,
redo the test and attach the dmesg output.
Created attachment 18796 [details]
debug patch
sorry, wrong patch attached.
Created attachment 18813 [details] Dmesg for patch from comment #19 23:15 - Boot. Brightness goes up to 100% 23:17 - echo 62 > /proc/acpi/video/VGA/LCD/brightness. The actual brightness changes, and that file has the correct value, but both backlight brightness files (acpi_video0, acpi_video1) still say level 7 (100%). 23:19 - I go to console using Ctrl-Alt-F1. The actual brightness goes to 100%. The /proc file still says 62%, but both backlight device files say level 7 (100%). 23:19 - Return to xorg (Ctrl-Alt-F7). Actual brightness is still at 100%, the file values are unchanged. 23:21 - I press the brightness up/down switches a few times. The values in the brightness files never change. 23:22 - echo {3,4} > /sys/class/backlight/acpi_vide0/brightness (a few times). Actual brightness changes. the /proc file changes accordingly. acpi_video0/brightness also changes, but acpi_video1/brightness remains the same. Hi, Marc, nice bug report. :) one question, at 23:17, how did you know /proc/acpi/video/VGA/LCD/brightness has the correct value, and acpi_video0, acpi_video1 still say level 7? did you "cat" them? it's really strange because there is no debug output at 23:17 showing that you tried to get the brightness level. will you please do the following test? 1. set the brightness value via /proc/acpi/video/VGA/LCD/brightness 2. "cat /proc/acpi/video/VGA/LCD/brightness" 3. "cat /sys/class/backlight/acpi_vide0/brightness" 4. "cat /sys/class/backlight/acpi_vide1/brightness" 5. wait for a minute, 6. set the brightness value via /sys/class/backlight/acpi_vide0/brightness(only once) 7. redo 2,3 and 4 8. attach the dmesg output. Please try Linux-2.6.28-rc4 or later, with the i915 and ACPI video drivers included. The OSI on the brightness here specifies Vista, and Vista includes IGD support that we've recently added to the i915 and the video driver that should handle brightness. Hello Zhang, In response to comment 22 : after every step in the test I did, I used "cat" to view the contents of the /proc and the 2 /sys brightness files. There is debug output at 23:17, but just one line. That's all that gets logged when I echo a value into /proc../brightness. I just tried it again right now, and there's only 1 new line in dmesg. I will redo the test you asked for, and try the latest rc kernel per Len Brown's request. Thank you all again for looking into this. Created attachment 18836 [details] commands and output for test in comment 22 Hi, Marc, you don't need to do the test in comment #22. (In reply to comment #21) > 23:15 - Boot. Brightness goes up to 100% good, the ACPI video driver set the brightness level to maximum if no _BQC available. > 23:17 - echo 62 > /proc/acpi/video/VGA/LCD/brightness. The actual brightness > changes, and that file has the correct value, but both backlight brightness > files (acpi_video0, acpi_video1) still say level 7 (100%). good. the ACPI control methods works on this laptop. and the "brightness" file only returns a cached value, in order to get the real brightness level, you need to run "cat actual_brightness" > 23:19 - I go to console using Ctrl-Alt-F1. The actual brightness goes to > 100%. this is strange, this is not done by ACPI driver. please do this test, unload the ACPI video driver before you go to console. does the brightness still goes to 100%? > The /proc file still says 62%, but both backlight device files say level 7 > (100%). > 23:19 - Return to xorg (Ctrl-Alt-F7). Actual brightness is still at 100%, > the > file values are unchanged. > 23:21 - I press the brightness up/down switches a few times. The values in > the brightness files never change. this is weird, the dmesg shows that ACPI video driver does change the brightness level upon hotkey event, please press the brightness down button for 5 times, if the brightness doesn't change, attach the output of "cat /proc/.../brightness" BTW: please attach the output of "xrandr --verbose". please run "xrandr --verbose | grep BACKLIGHT", if the BACKLIGHT_CONTROL is not "kernel" mode, please run "xrandr --output LVDS --set BACKLIGHT_CONTROL kernel" and check if this helps. (In reply to comment #26) > Hi, Marc, > you don't need to do the test in comment #22. Too late :) > (In reply to comment #21) > > 23:15 - Boot. Brightness goes up to 100% > good I respectfully disagree :) > > 23:17 - echo 62 > /proc/acpi/video/VGA/LCD/brightness. The actual > brightness > > changes, and that file has the correct value, but both backlight brightness > > files (acpi_video0, acpi_video1) still say level 7 (100%). > good. the ACPI control methods works on this laptop. > and the "brightness" file only returns a cached value, in order to get the > real > brightness level, you need to run "cat actual_brightness" I will use actual_brightness from now on. > > 23:19 - I go to console using Ctrl-Alt-F1. The actual brightness goes to > 100%. > this is strange, this is not done by ACPI driver. > please do this test, unload the ACPI video driver before you go to console. > does the brightness still goes to 100%? No, it does not. There are absolutely no brightness changes under any circumstance when video.ko is not loaded. > > 23:21 - I press the brightness up/down switches a few times. The values in > > the brightness files never change. > this is weird, the dmesg shows that ACPI video driver does change the > brightness level upon hotkey event, please press the brightness down button > for > 5 times, if the brightness doesn't change, attach the output of "cat > /proc/.../brightness" The hotkeys change the physical brightness, but the files remain unchanged. I have just used the keys to reduce the brightness to a very low level, but /proc.. still says 100%. [root@~] cat /proc/acpi/video/VGA/LCD/brightness levels: 100 37 12 25 37 50 62 75 87 100 current: 100 > BTW: please attach the output of "xrandr --verbose". > please run "xrandr --verbose | grep BACKLIGHT", > if the BACKLIGHT_CONTROL is not "kernel" mode, > please run "xrandr --output LVDS --set BACKLIGHT_CONTROL kernel" > and check if this helps. BACKLIGHT_CONTROL is "kernel". I'll attach the output in a moment. Created attachment 18839 [details]
Output of "xrandr --verbose"
(In reply to comment #27) > (In reply to comment #26) > > > 23:19 - I go to console using Ctrl-Alt-F1. The actual brightness goes to > 100%. > > this is strange, this is not done by ACPI driver. > > please do this test, unload the ACPI video driver before you go to console. > > does the brightness still goes to 100%? > > No, it does not. There are absolutely no brightness changes under any > circumstance when video.ko is not loaded. > > > > 23:21 - I press the brightness up/down switches a few times. The values > in > > > the brightness files never change. > > this is weird, the dmesg shows that ACPI video driver does change the > > brightness level upon hotkey event, please press the brightness down button > for > > 5 times, if the brightness doesn't change, attach the output of "cat > > /proc/.../brightness" > > The hotkeys change the physical brightness, good. :) > but the files remain unchanged. I > have just used the keys to reduce the brightness to a very low level, but > /proc.. still says 100%. > [root@~] cat /proc/acpi/video/VGA/LCD/brightness > levels: 100 37 12 25 37 50 62 75 87 100 > current: 100 > hmmm, there are two directories under /proc/acpi/video/, right? what's the content of /proc/acpi/video/GFX0/DD04/brightness? what's the content of /sys/.../acpi_video{0,1}/actual_brightness? I suspect that some other applications, maybe X, changes the backlight when you press ctrl+alt+f1. but it's still weird that the value of the procfs I/F is not updated correctly. Created attachment 18850 [details] Various commands that show the brightness file levels w/ 2.6.27.5 Hello Zhang, I have created a file which I hope will answer all your questions in comment #29. It is a test in 5 parts. I have found 2 cases where the brightness does not go back to 100% after switching to console. In both cases, acpi_video1/brightness contains the correct value (that matches the physical level), and is non-zero. In my previous tests, I always used acpi_video0, which is probably why I never found these 2 successful cases before. I also discovered this, in /var/log/Xorg.0.log: (II) intel(0): found backlight control method /sys/class/backlight/acpi_video1 excellent tests and valuable info. You make my work much easier, Marc. :) The problem is caused by some wrong interactions between ACPI and some user applications, maybe X. so the next step is, 1. kill acpid, run "cat /proc/acpi/event", is there any output if you switch to console and get back to X for several times? 2. pull linus' git tree to get the latest kernel source. there is a patch set shipped in yesterday, which can fix the duplicate video devices issue for you. and IMO, it would also help for this bug. if the problem still exists, please re-do the tests in comment #30 and attach the test result. BTW, I really like it. :p (In reply to comment #31) > 1. kill acpid, run "cat /proc/acpi/event" ... Sorry, no output from /proc/acpi/event with acpid killed. > 2. pull linus' git tree ... This will unfortunately have to wait several days. Take the week off! :P hah, any update? Created attachment 19021 [details] Tests with 2.6.28-rc6 from git Sorry for the long delay. I finally pulled a kernel from git and redid the big test from comment 30. First of all, the test is smaller because /proc/acpi/video/VGA and /sys/class/backlight/acpi_video1 no longer exist. I now only have /proc/acpi/video/GFX0 and /sys/class/backlight/acpi_video0. There's been a lot of progress with this new kernel. All tests are good except #1. When actual_brightness = 0, the brightness still gets reset to 100%. There is still progress with the failed test: before, the brightness would go to max as soon as I switched to the console. Now, it only happens when I return to xorg. Disregard the first line in attachment #19021 [details]. The tests were not done with 2.6.27.5.
according to ZhangYu's explanation, the graphics driver saves the backlight value before switching to console, and then restore it when switching back to X. the only exception is the zero brightness level. it's thought to be invalid and the maximum brightness value will be restored instead. cc Zhangyu. ZhenYu has already generate a patch and he'll push this to xf86-video-intel master ASAP. Reject this as it's not an Linux/ACPI bug. Marc, patch is at http://marc.info/?l=linux-acpi&m=122831633210069&w=2 you can give it a try if you want. :) |