Difference between revisions of "Problem with LCD brightness buttons"

From ThinkWiki
Jump to: navigation, search
(Affected Models)
(Update page with a lot more precise information)
Line 1: Line 1:
 
== Affected Models ==
 
== Affected Models ==
* {{X60}}
+
* {{X60}}, {{X60s}} with BIOS 2.x
* {{X60s}} -- https://bugs.freedesktop.org/show_bug.cgi?id=9355
+
* {{T60}}, {{T60p}} with BIOS 2.x
* Others?
 
  
A recent change in one of the newer Lenovo bios updates for (at least for the x60) seems to have swaped the acpi keycode for increasing brightness with the acpi code for swaping displays (err... primary to external I believe).  
+
A recent change in one of the newer Lenovo bios updates changed the brightness up key to also provide a ACPI video brighness up event.  This made ThinkPad users suffer from a bug in the Linux kernel handling of ACPI video events.
  
The undesireable behavior is that when trying to increase brightness, the display (for X) completely goes blank.
+
== Details ==
  
Bug reports:
+
The Linux kernel handling for the ACPI video event brighness up is not implemented by the ACPI video module before Linux 2.6.20-rc?, which results in the brightness up key not working, even if the event is handled correctly.
  
https://bugs.freedesktop.org/show_bug.cgi?id=9355
+
To make matters worse, the ACPI video module in kernels up to 2.6.19.1 has a hideous bug that gets many ACPI video events wrong, and this is the probable cause for the "tries to switch video output" effect some users observed, which can cause serious problems in certain configurations, like X server hangs.
  
 +
== Workaround ==
  
Details:
+
Do not load the ACPI video module, or compile in the ACPI_VIDEO option on Linux kernels that have not been patched to fix this issue.  The ThinkPad BIOS will do the right thing.
  
* Doesn't happen if acpid isn't running.
+
== Remaining issues ==
* Doesn't happen if you are in a vtty until all acpi events (will post the code with some logs later) are processed.
 
* The behavior of the display going out and not coming back may be related to the i810 driver.
 
  
Tested on:
+
Even with 2.6.20-rc3 ACPI video, things are still not perfect.  This time, it may be Lenovo's fault.
* Fedora Core 6 (same behavior)
+
 
* Kubuntu Edgy 6.10 (same behavior)
+
The fixed ACPI video module will use the ACPI DSDT to increase video brighness, but the new BIOS DSDTs apparently do not keep the CMOS NVRAM completely up-to-date, so tpb and other utilities that provide on-screen-display do not get to know there was a brightness up event.  This can be argued to be a deficiency on tpb, however.
 +
 
 +
Given that, if nothing handles the ACPI video brighness up event, the BIOS does the right thing, it is unclear at this time exactly where the blame for this remaining issue should lie.

Revision as of 18:05, 3 January 2007

Affected Models

A recent change in one of the newer Lenovo bios updates changed the brightness up key to also provide a ACPI video brighness up event. This made ThinkPad users suffer from a bug in the Linux kernel handling of ACPI video events.

Details

The Linux kernel handling for the ACPI video event brighness up is not implemented by the ACPI video module before Linux 2.6.20-rc?, which results in the brightness up key not working, even if the event is handled correctly.

To make matters worse, the ACPI video module in kernels up to 2.6.19.1 has a hideous bug that gets many ACPI video events wrong, and this is the probable cause for the "tries to switch video output" effect some users observed, which can cause serious problems in certain configurations, like X server hangs.

Workaround

Do not load the ACPI video module, or compile in the ACPI_VIDEO option on Linux kernels that have not been patched to fix this issue. The ThinkPad BIOS will do the right thing.

Remaining issues

Even with 2.6.20-rc3 ACPI video, things are still not perfect. This time, it may be Lenovo's fault.

The fixed ACPI video module will use the ACPI DSDT to increase video brighness, but the new BIOS DSDTs apparently do not keep the CMOS NVRAM completely up-to-date, so tpb and other utilities that provide on-screen-display do not get to know there was a brightness up event. This can be argued to be a deficiency on tpb, however.

Given that, if nothing handles the ACPI video brighness up event, the BIOS does the right thing, it is unclear at this time exactly where the blame for this remaining issue should lie.