Most recent kernel where this bug did not occur: 2.6.23-rc2 Distribution: Fedora 8 Hardware Environment: Toshiba Satellite Pro A100 laptop (C2D T5500, NV7600Go, ...) Problem Description: From kernel 2.6.23-rc3 onwards, I am no longer able to adjust the brightness of my laptop screen with the Fn+F6/7 keys. 2.6.23-rc3 will just do nothing when pressing them, 2.6.23-rc4 onwards shows up F6/F7 key events when pressing those hotkeys. Manually adjusting the brightness by writing to /proc/acpi/video/VGA/LCD/brightness still works. Manually reverting the embedded controller driver (ec.c) to 2.6.23-rc2 state makes backlight control work again, although key events still are sent. Using git head ec.c doesn't work. Please tell me if any additional information is needed.
Created attachment 13335 [details] acpidump output
Created attachment 13347 [details] Test patch by Alexey Starikovskiy that restores brightness buttons functionality.
Could you please check 2.6.24-rc1 version? >> Please check if attached patch changes situation. > Yes, it does. With that patch, everything works as intended. > Gnome-power-manager doesn't seem to work properly with it, but that's a > different story ;-) I fear it's related. dmesg would be helpful.
(In reply to comment #3) > Could you please check 2.6.24-rc1 version? > >> Please check if attached patch changes situation. > > > Yes, it does. With that patch, everything works as intended. > > Gnome-power-manager doesn't seem to work properly with it, but that's a > > different story ;-) > I fear it's related. dmesg would be helpful. Maybe my statement was confusing: gpm doesn't work properly with both the -rc2 kernel and your patch. If shows that pretty OSD-like thingy, but won't allow me to adjust the brightness to more than 50%. Trying to increase the brightness further will only result in a short flicker. I will try to build gpm with debug output to see what's going on. dmesg shows nothing while pressing brightness hotkeys (or do you want the full dmesg output since kernel startup?), will attach the output in /var/log/messages.
Created attachment 13348 [details] Output in /var/log/messages when pressing brightness buttons This is the output in /var/log/messages for a single Brightness-Down press followed by a single Brightness-Up press. Obviously (incorrectly?) two ACPI events are sent per button press.
(In reply to comment #3) > Could you please check 2.6.24-rc1 version? Of ec.c or the full kernel? For the former, I am already trying the Git HEAD version. For the latter, I will try ASAP; which probably will be after F8 release. If you could tell me which subset also needs updates, I would really appreciate that.
Created attachment 13349 [details] Full dmesg output Full dmesg output after start. About the Nvidia driver: The situation is completely unchanged when unloading the Nvidia module and using the nv X driver.
ok, for gpm issue this patch might help: commit 63f0edfc0b7f8058f9d3f9b572615ec97ae011ba Author: Alexey Starikovskiy <astarikovskiy@suse.de> Date: Mon Sep 3 16:30:08 2007 +0400 ACPI: VIDEO: Adjust current level to closest available one. Signed-off-by: Alexey Starikovskiy <astarikovskiy@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
rc3 was kind of broken for handling _Qxx events, see bug 8886, patch went into rc4, so the current state is: Fn-F6/F7 brightness events turned into F6/F7 keyboard events between rc2 and rc4, not doing early init of EC helps.
Created attachment 13354 [details] Do early init only for fake _INI being present Please check this patch
(In reply to comment #10) > Created an attachment (id=13354) [details] > Do early init only for fake _INI being present > > Please check this patch It works fine. The patch from comment #8 doesn't help for gpm, though. It seems like the gpm issue is related to two ACPI events being sent per key press. Gpm tries to set the brightness itself on the second event (it doesn't act on the first one) to a value not listed in the valid value table (_BCL) which causes the brightness to drop to the lowest level (driven by the firmware I guess). Maybe the new brightness should be validated in acpi_video_device_set_level (so the validation should be moved from acpi_video_device_write_brightness to this function)? If desired, I can provide a patch for that - I will play around with that anyway.
Additional question: The brightness change notify events are driven by the firmware, right? So there's no chance to fix the duplicate events besides a custom DSDT, is it?
(In reply to comment #11) > The patch from comment #8 doesn't help for gpm, though. It seems like the gpm > issue is related to two ACPI events being sent per key press. Gpm tries to > set > the brightness itself on the second event (it doesn't act on the first one) > to > a value not listed in the valid value table (_BCL) which causes the > brightness > to drop to the lowest level (driven by the firmware I guess). Maybe the new > brightness should be validated in acpi_video_device_set_level (so the > validation should be moved from acpi_video_device_write_brightness to this > function)? If desired, I can provide a patch for that - I will play around > with > that anyway. I posted a patch for that issue to bug 9277: http://bugzilla.kernel.org/show_bug.cgi?id=9277
Re comment#12, the duplicate events is caused by duplicate video buses in your DSDT. Event is sent to each of the video bus and that's why you got two acpi notifications for every hotkey pressing. We are still looking for a solution of the duplicate video bus device issue.
Created attachment 13546 [details] typo fixed Len, please send this one up.
27792f3af1f67057fc17e4bd3b28d0ce8fe1d15c (ACPI: EC: Don't init EC early if it has no _INI) applied to acpi test branch
shipped in linux-2.6.24-rc4 closed.
Created attachment 17499 [details] try the debug patch to see whether the system will be affected by this patch Hi, Danny Will you please try the attached patch and see whether the system will be affected by it? Thanks.
(In reply to comment #18) > Created an attachment (id=17499) [details] > try the debug patch to see whether the system will be affected by this patch > > Hi, Danny > Will you please try the attached patch and see whether the system will be > affected by it? > Thanks. Will do ASAP. Which tree (and additional patches) do I need to test this one?
(In reply to comment #19) > (In reply to comment #18) > > Created an attachment (id=17499) [details] [details] > > try the debug patch to see whether the system will be affected by this > patch > > > > Hi, Danny > > Will you please try the attached patch and see whether the system will be > > affected by it? > > Thanks. > > Will do ASAP. Which tree (and additional patches) do I need to test this one? I tried the patch on a snapshot of 2.6.27-rc5 in Linus' tree (commit d210baf53b699fc61aa891c177b71d7082d3b957). Brightness hotkeys continue to work just fine.
Hi, Danny thanks for the test. It is very lucky that your system won't be affected by the patch in comment #18. Thanks again.