I know that many brightness-related problems are already known, but mine seems to still leak a good description. I'm running an X60s with a vanilla 2.6.27-rc8 kernel (but I get the problem also with older versions). I also think that this description is valid also for the X60. I have no HAL running nor other particular hardware monitoring or power saving daemons. What I'm going to describe happens even without starting X (the behavior is exactly the same). Scenario 1. I load the acpi video module and I DON'T load the thinkpad_acpi module. Everything works file: I have the brightness control and I can read the correct acpi events with acpi_listen. But hey! I want to use those hotkeys, so I modprobe thinkpad_acpi. Scenario 2. video.ko and thinkpad_acpi.ko are both loaded. The latter warns me that it won't touch the brightness stuff, is acpi's duty! Here is the message: thinkpad_acpi: Lenovo BIOS switched to ACPI backlight control mode thinkpad_acpi: standard ACPI backlight interface available, not loading native one... And thats ok. And I get the hotkeys working! At a first sight even the brightness control seems to work, BUT, if (and only if) I reach the lowest level of brightness and I press the brightness-down key combination once again I get TWO acpi events from acpi_listen: video LCD0 00000087 00000000 ibm/hotkey HKEY 00000080 00005010 and the brightness control is messed up! Every change in brightness takes a long time to occur (almost a second), and this is very annoying. I get a double acpi event for every change in brightness, UNLESS I press the key combination too fast. In this case only the last event is double. Here's a series of brightness-up events: video LCD0 00000086 00000000 video LCD0 00000086 00000000 video LCD0 00000086 00000000 video LCD0 00000086 00000000 video LCD0 00000086 00000000 ibm/hotkey HKEY 00000080 00005010 Even in this case the effect of the key strokes is lagged. I want to remark that this doesn't happen if I reach the upper brightness limit and then press the brightness-up key combination once again! A strange asymmetry, isn't it? What happens then if I try to unload thinkpad_acpi? One thing I was partially not expecting: the ibm/hotkey acpi event disappears, but the brightness changes continue to be lagged! And the same happens if I rmmod and then modprobe the video module. The only way to bring things to normality seems to be a reboot. At the moment, at least for me, the most sane solution is not to load thinkpad_acpi (and renounce to the hotkeys). I can assure you that this lagging problem is really annoying! I hope this description is sufficiently precise. Of course I'm available for giving further informations and testing patches or workarounds. Paride ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
