Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I've got a Thinkpad and would like to use the ThinkLight (the white flash light above the screen designed to light up the keyboard) for notifications on incoming Jabber messages.

It is easy to realise as one only needs to change /sys/class/leds/tpacpi::thinklight/brightness to 255. I'll do it with a simple Bash script, which will let the light blink for three times.

But to be able to do this, I need to change the permissions, that not only root is able to change this file.
And I do not want to sudo chmod o+w /sys/class/leds/tpacpi::thinklight/brightness after each and every boot.

I think, the best solution is using udev for this. However, I've never used udev before and I'm quite confused by the tutorials I found online.

I tried this udev rule:

KERNEL=="tpacpi::thinklight", MODE="0666"

as well as

KERNEL="thinklight", MODE="0666"

But it does not work. Though I'm not getting errors while running udevadm test /class/leds

Thanks for any help and hits. Or maybe other solutions.

share|improve this question

migrated from stackoverflow.com Sep 5 '11 at 10:25

This question came from our site for professional and enthusiast programmers.

good idea with the notification, gotta do that too :) thanks –  K1773R May 18 at 8:34

2 Answers 2

I think you have the wrong 'KERNEL' setting. From this awesome doc for writing and debugging udev rules:


I think you need KERNEL=brightness, and perhaps a SUBSYSTEM=leds

Then, in case your distro lacks inotify support. Make sure your changes are being seen by udevd:

# udevcontrol reload_rules
share|improve this answer

I'm using two udev rules as follows, to give members of group leds access to all LEDs:

SUBSYSTEM=="leds", ACTION=="add", RUN+="/bin/chgrp -R leds /sys%p", RUN+="/bin/chmod -R g=u /sys%p"
SUBSYSTEM=="leds", ACTION=="change", ENV{TRIGGER}!="none", RUN+="/bin/chgrp -R leds /sys%p", RUN+="/bin/chmod -R g=u /sys%p"

Note the ACTION=="change" rule is needed to handle dynamically created attributes. For example, if the LED's trigger is set to "timer" (echo timer > trigger), then extra attributes delay_on and delay_off are created. The change action is specified so that these new attributes have their group and permissions set.

I've noticed that a change event is generated every time the LED is turned off by writing 0 to /sys/class/leds/.../brightness. This seems to be due to the Linux LED driver code clearing triggers whenever brightness is set to 0. That is why the second rule has the ENV{TRIGGER}!="none" condition, to prevent the rule triggering every time an LED is turned off.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.