☰

A nova "filosofia" do udev

tag-icon • tag-icon 13.04 udev xinput
A nova "filosofia" do udev

Aqui está uma regra do meu /lib/udev/rules.ddiretório:

SUBSYSTEM=="input", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="008c", RUN+="/home/mikeknoop/scripts/udev-receiver.sh"

Aqui está o conteúdo simples do udev-receiver.shscript:

#!/bin/bash

echo "UDEV-RECEIVER INIT" >> /var/log/external.log

{
sleep 5;
echo "Done" >> /var/log/external.log
} &

echo "UDEV-RECEIVER FINISH" >> /var/log/external.log

Quando eu conecto meu dispositivo, a saída external.logé a esperada:

UDEV-RECEIVER INIT
UDEV-RECEIVER FINISH
Done

No entanto, também estou acompanhando o syslog /var/log/sysloge posso ver que, embora eu tenha bifurcado o sleepprocesso de longa execução, udeva inicialização do dispositivo está bloqueando até Doneaparecer no meu external.logarquivo.

A razão pela qual isso é importante é porque estou tentando definir algumas propriedades do dispositivo, xinputmas o dispositivo não é listado xinput listaté que toda a udevinicialização seja concluída (até depois de Doneaparecer em external.log).

De acordo comudev(7) - página de manual do Linux

"Adicione um programa à lista de programas a serem executados para um dispositivo específico. Isso só pode ser usado para tarefas de execução muito curtas. A execução de um processo de evento por um longo período de tempo pode bloquear todos os eventos adicionais para este ou um dispositivo dependente. Tarefas de longa duração precisam ser imediatamente separadas do próprio processo de evento."

Não consigo conciliar a página de manual e o comportamento que estou vendo. Alguém pode esclarecer ou oferecer uma maneira melhor de definir propriedades xinputquando um dispositivo é inserido?

Obrigado!

Responder1

Respondendo à minha própria pergunta depois de muitas pesquisas adicionais.

A nova "filosofia" do udev

Aparentemente, a nova maneira "adequada" de usar udevé não incorrer em processos de longa duração.

Através dahttp://blog.fraggod.net/2012/06/16/proper-ish-way-to-start-long-running-systemd-service-on-udev-event-device-hotplug.html:

RUN ... Iniciar daemons ou outros processos de longa execução não é apropriado para o udev; os processos bifurcados, desanexados ou não, serão eliminados incondicionalmente após o término do tratamento do evento.

Observe como isso está em contradição com a citação da página de manual no OP.

Meu melhor palpite é que uma udevmudança recente (~2012 em algum momento) força todos os processosIncluindoseus filhos bifurcados terminem antes de permitir que a execução continue como um mecanismo de aplicação desta nova filosofia.

Portanto, toda a documentação e respostas facilmente acessíveis na web que fornecem o padrão no OP como solução estão agora quebradas.

A nova filosofia de padrão de longa duração é compreensível quando você está falando sobre algum daemon que está sempre em execução quando o dispositivo está conectado. No entanto, isso elimina o defercaso de uso efetivo junto com ele.

Gambiarra

No entanto, também descobri uma solução alternativa:

/lib/udev/rules.d/98-mouse-config.rules/

SUBSYSTEM=="usb", ATTRS{idVendor}=="045e", ATTRS{idProduct}=="008c", ACTION=="add|remove", ENV{ID_TYPE}!="hid", RUN+="/home/mikeknoop/scripts/udev-receiver.sh"

udev-receiver.sh

#!/bin/bash
echo /home/mikeknoop/scripts/mouse.sh | at now

mouse.sh

#!/bin/bash
sleep 3;
export DISPLAY=":0.0"
export XAUTHORITY="/home/mikeknoop/.Xauthority"
/usr/bin/xinput --set-prop 'pointer:Microsoft Microsoft Wireless Optical Mouse® 1.0A' 'Device Accel Constant Deceleration' 2.00000
... more xinput rules here

ObservaçãoIsso foi testado e funciona no Ubuntu 13.04

ObservaçãoVocê precisará instalar atum pacote de tarefas assíncronas viasudo apt-get install at

Eu juntei a solução alternativa dehttps://unix.stackexchange.com/questions/28548/how-to-run-custom-scripts-upon-usb-device-plug-in

informação relacionada