Como posso alterar as permissões em / sys para alterar o estado de um LED / luz usando 'udev'?

Question

Eu tenho um Thinkpad e gostaria de usar o ThinkLight (a luz branca do flash acima da tela projetada para iluminar o teclado) para receber notificações sobre as mensagens do Jabber.

É fácil perceber que só é necessário alterar /sys/class/leds/tpacpi::thinklight/brightness para 255. Eu faço isso com um simples script Bash, que deixa a luz piscar por três vezes.

Mas, para poder fazer isso, eu preciso alterar as permissões, que não só o root é capaz de alterar este arquivo.
E eu não quero sudo chmod o+w /sys/class/leds/tpacpi::thinklight/brightness após cada inicialização.

Acho que a melhor solução é usar udev para isso. No entanto, nunca usei udev e estou bastante confuso com os tutoriais que encontrei on-line.

Eu tentei esta regra udev :

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

bem como

KERNEL="thinklight", MODE="0666"

Mas isso não funciona. Embora eu não esteja recebendo erros durante a execução de udevadm test /class/leds

Obrigado por qualquer ajuda e visitas. Ou talvez outras soluções.

    

Answer 1

Estou usando duas regras do udev, como segue, para fornecer aos membros do grupo leds acesso a todos os 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"

Observe que a regra ACTION=="change" é necessária para manipular atributos criados dinamicamente. Por exemplo, se o gatilho do LED estiver definido como "timer" ( echo timer > trigger ), os atributos extras delay_on e delay_off serão criados. A ação change é especificada para que esses novos atributos tenham seus grupos e permissões definidos.

Percebi que um evento change é gerado toda vez que o LED é desativado escrevendo 0 to /sys/class/leds/.../brightness . Isso parece dever-se ao fato de a limpeza do código do driver LED do Linux ser acionada sempre que o brilho é definido como 0 . É por isso que a segunda regra tem a condição ENV{TRIGGER}!="none" , para evitar que a regra seja acionada toda vez que um LED é desativado.

    

Answer 2

Eu acho que você tem o ajuste errado 'KERNEL'. A partir desse documento incrível para escrever e depurar as regras do udev:

link

Eu acho que você precisa de KERNEL = brilho e talvez um SUBSISTEMA = leds

Em seguida, no caso de sua distro não incluir suporte. Certifique-se de que suas alterações estão sendo vistas pelo udevd:

# udevcontrol reload_rules