Brain Dump

A place to store my random thoughts and anything else I might find useful.

Archive for the ‘Arch Linux’ Category

Linux: Enabling brightness control for Thinkpad W520

Posted by mzanfardino on February 10, 2015


1. Overview
2. Solution
3. Summary


I have a Lenovo ThinkPad W520 laptop and I’m running Arch Linux. Recently I’ve found that my brightness controls have not been working. Specifically the OSD for my dm (Cinnamon in my case) was reporting the brightness level changing but the screen backlight was not changing. I know this feature worked in the past which tells me that some change/update has ‘broken’ this functionality.

The solution required making two changes: one to grub.cfg and the other to xorg.conf. The change to grub.cfg enables the thinkpad-acpi brightness control events and the change to xorg.conf couples the key events to the acpi.


When researching this problem the first thing I took a look at was the boot log. Given that Arch has moved to systemd (a topic for another post) I used journalctl -b to search for references to ‘thinkpad’. I found the following entries:

Nov 10 17:13:49 enceladus kernel: thinkpad_acpi: ThinkPad ACPI Extras v0.25
Nov 10 17:13:49 enceladus kernel: thinkpad_acpi:
Nov 10 17:13:49 enceladus kernel: thinkpad_acpi: ThinkPad BIOS 8BET56WW (1.36 ), EC unknown
Nov 10 17:13:49 enceladus kernel: thinkpad_acpi: Lenovo ThinkPad W520, model 4270CTO
Nov 10 17:13:49 enceladus kernel: thinkpad_acpi: detected a 16-level brightness capable ThinkPad
Nov 10 17:13:49 enceladus kernel: thinkpad_acpi: radio switch found; radios are enabled
Nov 10 17:13:49 enceladus kernel: thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the AC
Nov 10 17:13:49 enceladus kernel: thinkpad_acpi: Disabling thinkpad-acpi brightness events by default...
Nov 10 17:13:49 enceladus kernel: thinkpad_acpi: Standard ACPI backlight interface available, not loading native one
Nov 10 17:13:49 enceladus kernel: thinkpad_acpi: Console audio control enabled, mode: monitor (read only)
Nov 10 17:13:49 enceladus kernel: input: ThinkPad Extra Buttons as /devices/platform/thinkpad_acpi/input/input8

The first thing I noticed was that the kernel was reporting that the thinkpad-acpi brightness events where disable. This lead me to conclude that a kernel flag was necessary in order to enable the thinkpad-acpi brightness events. After some research I found a post on Ubuntu Wiki[1] which suggested that I edit /etc/default/grub and added the following:

GRUB_CMDLINE_LINUX_DEFAULT="acpi_backlight=vendor thinkpad-acpi.brightness_enable=1"

Rebuilt grub.cfg using:

# grub-mkconfig -o /boot/grub/grub.cfg

The same Ubuntu Wiki post suggested a change to /etc/X11/xorg.conf. I changes my ‘Section “Device”‘ to include the following two lines:

BoardName "Quadro 1000M"
Option "RegistryDwords" "EnableBrightnessControl=1"

My new ‘Section “Device”‘ looks like the following:

Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "Quadro 1000M"
Option "RegistryDwords" "EnableBrightnessControl=1"

After rebooting I found that in the journal the thinkpad-acpi brightness events was no longer disabled however the brighness controls themselves were still not working correctly. Specifically I noticed that the OSD was no longer reporting a valid percentage value but was not reporting a value from 0 to 16. After a little more research I found a power on Arch Linux Wiki [2] which suggested that rather than using the “acpi_backlight=vendor” kernel flag I should be using the ‘acpi_osi=”!Windows 2012″‘ flag. I changed my grub.cfg linux default to the following:

GRUB_CMDLINE_LINUX_DEFAULT="acpi_osi=\"!Windows 2012\" thinkpad-acpi.brightness_enable=1"

I then rebuild grub.cfg and booted. This time my brightness controls worked as expected and the OSD was reporting the correct values. I was also able to verify that the brightness controls were working for any TTY terminal.

Although this solution worked, I did not like having the reference to “!Windows 2012” in my kernel flags – this is linux for crying out loud! Why do I have to make a Windows reference (despite the fact that evidently Lenovo changed the acpi driver to accommodate Windows). I found a reference to ‘acpi_osi=linux’ in another Arch Linux wiki article[3] so I made one final change to my kernel flag in grub to the following:

GRUB_CMDLINE_LINUX_DEFAULT="acpi_osi=linux thinkpad-acpi.brightness_enable=1"

After rebuilding grub.cfg everything worked as expected.


As a result of a change in the thinkpad-acpi driver (evidently) the default behavior for brightness control is disabled. This requires that the kernel be notified through a flag to enable the brightness events. In addition to enabling the events the kernel needs to be notified that this osi is linux (not Windows). This is handled by a separate flag. Finally, xorg needs to be configured to handle the brightness controls as well. Once both the bootloader and x11 are configured correctly the brightness controls should work.

Please note that I’ve made a number of assumptions. I’m assuming the bootloader is grub – I presume other bootloaders will permit kernel flags to be set. I’m also presuming the use of xorg.conf. If this isn’t your case, please feel free to drop me a comment with how you were able to resolve your individual problem.

[1] Screen brightness control not working on Lenovo T530
[2] Thinkpad T430 backlight control
[3] Intel graphics


Posted in acpi, Arch Linux, grub, kernel, linux, thinkpad-acpi, xorg | Leave a Comment »

Problems with ThinkPad W520 handing during udev

Posted by mzanfardino on April 6, 2012


1. Overview
2. Solution
3. Summary


I’m going to keep this short. In summary, I just bought a ThinkPad W520 and found that when I attempt to install a number of the latest linux distros they all hang intermittently during boot. I decided to troubleshoot this using Arch Linux as my test platform, as I have no trouble booting from the netinst CD nor installing the OS.  However, after the OS is installed I have found that the system hangs more than 50% of the time during “Waiting to process udev events”.  Naturally I assumed the problem lay in udev. As of yesterday (April 5, 2012) the version of udev installed from core is 181-5. I opted to try udev from testing (udev 181-9). This did not improve things.


With some help from folks in #udev I was able to disable asynchronous processing and enable debugging from the kernel options in grub-legacy.  This helped me to identify a key clue: it never seemed to hang at the same spot.  I reasoned that if it was in fact udev that was failing, and given that I disabled asynchronous processing it seems highly unlikely that the problem was in fact with udev.

This led me to think of hardware, such as RAM or CPU as the source of the problem.  However, after several successful passes with memtest86+ 4.20 I was convinced that there was no problem with RAM.  This left the CPU.

After scouring the web for days and fighting with this issue for nearly a week, I finally came across a forum post for Fedora that suggested perhaps the problem lay with Intel Virtualization Technology being enabled.

And there it was: I’d turned on Intel-VT when I first booted the machine and never ran it with Intel-VT turned off. After turning Intel-VT off I have been able to successfully boot to Arch 100% of the time!


As udev has nothing (directly) to do with Intel-VT, it’s highly unlikely that udev is the problem. It’s more likely udev is loading a module (it has been suggested to me by a friend of mine Ewen Marshall that  kvm is the likely suspect) which is the real culprit. I will be performing tests this weekend in an effort to isolate the offending module and hopefully then open a bug with the developers of the module in an effort to help solve the problem.

ED – I found this recently which suggests that perhaps it’s localized to VT-d (and not the entire VT) in combination with discrete video.  I happen to be running with discrete video enabled in BIOS as well, and haven’t (yet) tried to boot with VT enabled and VT-d disabled.  I will try that in addition to my other tests this weekend and will report back later.

ED – I can confirm that the issue appears to be related to the VT-d.  I have enabled VT and left VT-d disabled.  I will begin further research as time permits.

Posted in Arch Linux, linux | 3 Comments »