Difference between revisions of "Problem with LCD brightness buttons"
(→Workaround) |
(→Change permissions on the brightness file) |
||
| (4 intermediate revisions by the same user not shown) | |||
| Line 21: | Line 21: | ||
There are a number of workarounds for this problem. After applying the workarounds, you will be able to use brightness up {{key|Fn}}{{key|Home}} and brightness down {{key|Fn}}{{key|End}} to increase and decrease the LCD brightness as normal. | There are a number of workarounds for this problem. After applying the workarounds, you will be able to use brightness up {{key|Fn}}{{key|Home}} and brightness down {{key|Fn}}{{key|End}} to increase and decrease the LCD brightness as normal. | ||
| − | '''Note for T420s users:''' Using the workarounds listed below in Linux Mint 19.1 introduces a weird bug, whereby the brightness is reset every time the power cord is plugged or unplugged. It also disables the brightness keys when we are at the login screen. | + | '''Note for T420s users:''' Using the workarounds listed below (except the chmod workaround) in Linux Mint 19.1 MATE introduces a weird bug, whereby the brightness is reset every time the power cord is plugged or unplugged. It also disables the brightness keys when we are at the login screen. This does not occur on Linux Mint 19.1 Cinnamon and Ubuntu 18.04.1 Desktop. In fact, for those distros we do not need to apply any of the workarounds below at all. |
=== Don't load the ACPI video module === | === Don't load the ACPI video module === | ||
| Line 28: | Line 28: | ||
For Fedora Core 6 users, issue the following command and reboot: | For Fedora Core 6 users, issue the following command and reboot: | ||
| − | + | # rename ko ko.old /lib/modules/$(uname -r)/kernel/drivers/acpi/video.ko | |
=== Specify a parameter for video.ko === | === Specify a parameter for video.ko === | ||
| Line 36: | Line 36: | ||
There is a number of ways to introduce this parameter, one of them is creating a configuration file for modprobe. The next command works on Debian 6 (and maybe some other systems): | There is a number of ways to introduce this parameter, one of them is creating a configuration file for modprobe. The next command works on Debian 6 (and maybe some other systems): | ||
| − | + | # echo options video brightness_switch_enabled=0 | tee /etc/modprobe.d/video-br.conf | |
=== Modify the parameter for video.ko at runtime === | === Modify the parameter for video.ko at runtime === | ||
| Line 42: | Line 42: | ||
Another alternative, one can issue this command or put it in <code>/etc/rc.local</code>: | Another alternative, one can issue this command or put it in <code>/etc/rc.local</code>: | ||
| − | echo N | + | # echo N | tee /sys/module/video/parameters/brightness_switch_enabled |
=== Update Grub loading === | === Update Grub loading === | ||
| Line 50: | Line 50: | ||
Add to GRUB_CMDLINE_LINUX_DEFAULT line in /etc/default/grub | Add to GRUB_CMDLINE_LINUX_DEFAULT line in /etc/default/grub | ||
video.use_native_backlight=0 | video.use_native_backlight=0 | ||
| + | |||
| + | === Change permissions on the brightness file === | ||
| + | |||
| + | Find the raw brightness control method: | ||
| + | |||
| + | $ grep -qs raw /sys/class/backlight/*/type | ||
| + | /sys/class/backlight/intel_backlight/type:raw | ||
| + | |||
| + | Then chmod the brightness file so the power manager can't write to it. | ||
| + | |||
| + | # chmod 444 /sys/class/backlight/intel_backlight/brightness | ||
| + | |||
| + | Incidentally, this also fixes the brightness reset upon plug or unplug of the power cable. | ||
== Remaining issues == | == Remaining issues == | ||
Latest revision as of 13:07, 7 April 2019
Contents
Affected Models
- X60, X60s with BIOS 2.x
- T60, T60p with BIOS 2.x
- R60 with BIOS 2.x
- X61s
- T420s
- Probably all newer ThinkPads since the Lenovo acquisition
Problem description
A recent change in one of the newer Lenovo BIOS updates changed the behavior of the brightness up/down keys, so that they also provide ACPI video brighness up/down events. This made ThinkPad users suffer from a bug in the Linux kernel handling of ACPI video events.
One problem is that when the brightness up FnHome or brightness down FnEnd key is pressed, that event is processed twice. It will seem to the user, that the brightness up/down keys work in steps of 2. For example, starting from 0, the brightness level will go up to 2, 4, 6, 8, 10, 12, 14, then 15. But from 15, the brightness level will go down to 13, 11, 9, 7, 5, 3, 1, then 0. It's weird behavior.
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
There are a number of workarounds for this problem. After applying the workarounds, you will be able to use brightness up FnHome and brightness down FnEnd to increase and decrease the LCD brightness as normal.
Note for T420s users: Using the workarounds listed below (except the chmod workaround) in Linux Mint 19.1 MATE introduces a weird bug, whereby the brightness is reset every time the power cord is plugged or unplugged. It also disables the brightness keys when we are at the login screen. This does not occur on Linux Mint 19.1 Cinnamon and Ubuntu 18.04.1 Desktop. In fact, for those distros we do not need to apply any of the workarounds below at all.
Don't load the ACPI video module
Don't load the ACPI video module, or don't 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.
For Fedora Core 6 users, issue the following command and reboot:
# rename ko ko.old /lib/modules/$(uname -r)/kernel/drivers/acpi/video.ko
Specify a parameter for video.ko
As an alternative, one might also specify brightness_switch_enabled=0 in video.ko parameters. With this parameter, all functionality of video.ko remains but without the brightness control and reaction to brightness ACPI events.
There is a number of ways to introduce this parameter, one of them is creating a configuration file for modprobe. The next command works on Debian 6 (and maybe some other systems):
# echo options video brightness_switch_enabled=0 | tee /etc/modprobe.d/video-br.conf
Modify the parameter for video.ko at runtime
Another alternative, one can issue this command or put it in /etc/rc.local:
# echo N | tee /sys/module/video/parameters/brightness_switch_enabled
Update Grub loading
From https://bbs.archlinux.org/viewtopic.php?id=184949&p=2
Add to GRUB_CMDLINE_LINUX_DEFAULT line in /etc/default/grub
video.use_native_backlight=0
Change permissions on the brightness file
Find the raw brightness control method:
$ grep -qs raw /sys/class/backlight/*/type /sys/class/backlight/intel_backlight/type:raw
Then chmod the brightness file so the power manager can't write to it.
# chmod 444 /sys/class/backlight/intel_backlight/brightness
Incidentally, this also fixes the brightness reset upon plug or unplug of the power cable.
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 of these tools, however. The foolproof, safe way to know the current ThinkPad display brightness in Linux is to ask ibm-acpi. Note that ibm-acpi support for this functionality is new, which explains why the current tools don't use it.
Due to the fact that when 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.
