¿Cómo puedo cambiar los permisos en / sys para alterar el estado de un LED / luz usando `udev`?

11

Tengo un Thinkpad y me gustaría usar ThinkLight (la luz de flash blanca sobre la pantalla diseñada para iluminar el teclado) para notificaciones de mensajes entrantes de Jabber.

Es fácil de realizar, ya que uno solo necesita cambiar /sys/class/leds/tpacpi::thinklight/brightnessa 255. Lo haré con un simple script Bash, que dejará que la luz parpadee tres veces.

Pero para poder hacer esto, necesito cambiar los permisos, que no solo la raíz puede cambiar este archivo.
Y no quiero sudo chmod o+w /sys/class/leds/tpacpi::thinklight/brightnessdespués de cada arranque.

Creo que la mejor solución es usar udevesto. Sin embargo, nunca lo he usado udevantes y estoy bastante confundido por los tutoriales que encontré en línea.

Probé esta udevregla:

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

tanto como

KERNEL="thinklight", MODE="0666"

Pero no funciona. Aunque no obtengo errores mientras ejecutoudevadm test /class/leds

Gracias por cualquier ayuda y éxitos. O tal vez otras soluciones.

Torbjörn
fuente
buena idea con la notificación,
tengo

Respuestas:

7

Estoy usando dos reglas de udev de la siguiente manera, para dar a los miembros del grupo ledsacceso a todos los LED:

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"

Tenga en cuenta que la ACTION=="change"regla es necesaria para manejar atributos creados dinámicamente. Por ejemplo, si el gatillo del LED se ajusta a "temporizador" ( echo timer > trigger), luego atributos adicionales delay_ony delay_offse crean. La changeacción se especifica para que estos nuevos atributos tengan su grupo y permisos establecidos.

Me di cuenta de que changese genera un evento cada vez que se apaga el LED escribiendo 0a /sys/class/leds/.../brightness. Esto parece deberse a que el código del controlador LED de Linux desencadena los activadores cada vez que se configura el brillo 0. Es por eso que la segunda regla tiene la ENV{TRIGGER}!="none"condición, para evitar que la regla se active cada vez que se apaga un LED.

Craig McQueen
fuente
1

Creo que tienes la configuración incorrecta 'KERNEL'. De este impresionante documento para escribir y depurar reglas de udev:

http://www.reactivated.net/writing_udev_rules.html#basic

Creo que necesitas KERNEL = brillo, y quizás un SUBSISTEMA = leds

Luego, en caso de que su distribución carece de soporte inotify. Asegúrese de que udevd esté viendo sus cambios:

# udevcontrol reload_rules
polinomio
fuente