☰

La nueva "filosofía" de udev

tag-icon • tag-icon 13.04 udev xinput
La nueva "filosofía" de udev

Aquí hay una regla de mi /lib/udev/rules.ddirectorio:

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

Aquí está el contenido simple del udev-receiver.shguión:

#!/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

Cuando conecto mi dispositivo, el resultado external.loges el que se esperaría:

UDEV-RECEIVER INIT
UDEV-RECEIVER FINISH
Done

Sin embargo, también estoy siguiendo el syslog /var/log/syslogy puedo ver que, aunque he bifurcado el sleepproceso de larga duración, udevla inicialización del dispositivo se bloquea hasta que Doneaparece después en mi external.logarchivo.

La razón por la que esto es importante es porque estoy intentando configurar algunas propiedades del dispositivo a través, xinputpero el dispositivo no aparece en la lista hasta que se completa xinput listla inicialización completa (hasta que aparece después en ).udevDoneexternal.log

De acuerdo con laudev(7) - página de manual de Linux

"Agregue un programa a la lista de programas que se ejecutarán para un dispositivo específico. Esto solo se puede usar para tareas de ejecución muy cortas. La ejecución de un proceso de evento durante un período de tiempo prolongado puede bloquear todos los eventos adicionales para este o un dispositivo dependiente. Las tareas de larga duración deben separarse inmediatamente del proceso del evento en sí".

No puedo conciliar la página de manual y el comportamiento que estoy viendo. ¿Alguien puede arrojar luz u ofrecer una mejor manera de configurar propiedades xinputcuando se inserta un dispositivo?

¡Gracias!

Respuesta1

Respondiendo a mi propia pregunta después de mucha investigación adicional.

La nueva "filosofía" de udev

Al parecer, la nueva forma "adecuada" de utilizarlo udeves no incurrir en procesos de larga duración.

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

EJECUTAR... Iniciar demonios u otros procesos de ejecución prolongada no es apropiado para udev; los procesos bifurcados, separados o no, se eliminarán incondicionalmente una vez finalizado el manejo del evento.

Tenga en cuenta cómo esto contradice la cita de la página de manual en OP.

Mi mejor suposición es que un udevcambio reciente (~2012 en algún momento) obliga a todos los procesosincluidosus hijos bifurcados terminen antes de permitir que la ejecución continúe como mecanismo de aplicación de esta nueva filosofía.

Por lo tanto, toda la documentación y las respuestas de fácil acceso en la web que brindan el patrón en OP como solución ahora no funcionan.

La nueva filosofía de patrón de larga duración es comprensible en el caso en que se habla de algún demonio que siempre se está ejecutando cuando el dispositivo está enchufado. Sin embargo, borra el defercaso de uso efectivo junto con él.

Solución alterna

No obstante, también descubrí una solución 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

NotaEsto fue probado y funciona en Ubuntu 13.04.

NotaDeberá instalar atcuál es un paquete de tareas asíncrono a través desudo apt-get install at

Reuní la solución alternativa dehttps://unix.stackexchange.com/questions/28548/how-to-run-custom-scripts-upon-usb-device-plug-in

información relacionada