Eu tenho esta regra UDEV, que é ativada quando eu conecto meu teclado:
ACTION=="add", DEVPATH=="/devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/0003:046A:0011.00??/input/input??/event[0-9][0-9]*", ATTRS{name}=="HID 046a:0011", ATTRS{phys}=="usb-0000:00:14.0-1/input0", RUN+="/home/*user*/.udev_rule_scripts/cherry_keyboard.sh", SYMLINK+="cherrysymlink"
Deveria
/dev/cherrysymlink , o que ele faz e Aqui está a saída de depuração de udevadm test /devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/0003:046A:0011.0003/input/input18/event17 :
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.
.INPUT_CLASS=kbd
ACTION=add
DEVLINKS=/dev/input/by-id/usb-046a_0011-event-kbd /dev/cherrysymlink /dev/input/by-path/pci-0000:00:14.0-usb-0:1:1.0-event-kbd
DEVNAME=/dev/input/event17
DEVPATH=/devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1:1.0/0003:046A:0011.0003/input/input18/event17
ID_BUS=usb
ID_INPUT=1
ID_INPUT_KEY=1
ID_INPUT_KEYBOARD=1
ID_MODEL=0011
ID_MODEL_ENC=0011
ID_MODEL_ID=0011
ID_PATH=pci-0000:00:14.0-usb-0:1:1.0
ID_PATH_TAG=pci-0000_00_14_0-usb-0_1_1_0
ID_REVISION=0100
ID_SERIAL=046a_0011
ID_TYPE=hid
ID_USB_DRIVER=usbhid
ID_USB_INTERFACES=:030101:
ID_USB_INTERFACE_NUM=00
ID_VENDOR=046a
ID_VENDOR_ENC=046a
ID_VENDOR_ID=046a
LIBINPUT_DEVICE_GROUP=3/46a/11/111:usb-0000:00:14.0-1
MAJOR=13
MINOR=81
SUBSYSTEM=input
USEC_INITIALIZED=31155231
run: '/usr/local/bin/cherry.sh'
Quando o teclado está conectado, /dev/cherrysymlink é criado. Além disso, a saída de depuração diz na última linha que o script /usr/local/bin/cherry.sh foi realmente executado.
O problema é que o script não é realmente executado.
cherry_keyboard.sh :
#!/bin/bash
xset r rate 150 60
Ele deve alterar a repetição automática das teclas do teclado, mas permanece o mesmo.
Eu também tentei:
#!/bin/bash
slock
Nada acontece. Quando executo os scripts manualmente no shell, ambos funcionam. O que estou fazendo errado?
EDITAR:
Depois de modificar meu script assim, posso enviar a echo em dzen2 para que ela apareça na tela:
#!/bin/bash
export DISPLAY=:0
export XAUTHORITY=/home/*user*/.Xauthority
echo 'test' > /home/*user*/.udev_rule_scripts/test
echo 'test' | dzen2 -p 4
xset r rate 150 60
slock
Até agora, os dois primeiros echo -lines funcionam. Os comandos xset e slock ainda não funcionam.
EDIT2:
Após algumas leituras, tenho certeza que tem algo a ver com o DBUS e a variável de ambiente "DBUS_SESSION_BUS_ADDRESS". Além disso, quando executo o printenv como usuário, há DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus set. Quando executo o printenv como root esta variável não está definida.
Por isso, fiz outra modificação no meu script:
#!/bin/bash
export DISPLAY=:0
export XAUTHORITY=/home/*user*/.Xauthority
export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
echo 'test' > /home/*user*/.udev_rule_scripts/test
echo 'test' | dzen2 -p 4
xset r rate 150 60
slock
Infelizmente, ainda não funciona.
EDIT3:
Após a sugestão de Gilles, adicionei uma linha ao script:
#!/bin/bash
exec >>/home/*user*/.udev_rule_scripts/test.log 2>&1; echo; date
export DISPLAY=:0
export XAUTHORITY=/home/*user*/.Xauthority
echo 'test' | dzen2 -p 4
xset r rate 150 60
slock
, que produz a seguinte mensagem de erro em test.log
Tue Feb 23 10:14:17 UTC 2016
/home/*user*/.udev_rule_scripts/cherry_keyboard: line 11: 858 Segmentation fault (core dumped) slock
qual (tipo de) explica por que slock falha em executar.
Infelizmente, não há nada sobre xset .
EDIT4:
Desta vez, combinei as sugestões de Gilles e ojs. Agora as mensagens de erro são mais interessantes:
cherry_keyboard.sh :
#!/bin/bash
exec >>/home/*user*/.udev_rule_scripts/test.log 2>&1; echo; date
export DISPLAY=:0
export XAUTHORITY=/home/*user*/.Xauthority
echo 'test' | dzen2 -p 4
su *user* -c "DISPLAY=:0 xset r rate 150 60"
su *user* -c "DISPLAY=:0 slock"
test.log:
Tue Feb 23 10:37:22 UTC 2016
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
after 43 requests (37 known processed) with 0 events remaining.
Tue Feb 23 10:38:37 UTC 2016
dzen: cannot open display
xset: unable to open display ":0"
slock: cannot open display
Tue Feb 23 10:40:54 UTC 2016
Agora aqui está a coisa: Quando eu insiro o meu teclado, dzen2 aparece na tela, então a tela fica preta. Mas não por causa do slock , ele cai e quando eu digito no teclado a tela fica preta (o que não deveria acontecer quando o slock estava por trás). Outros aplicativos como moc ainda estão em execução.
E agora a parte estranha:
Quando eu pressiono o botão liga / desliga no meu laptop para reiniciar o sistema (que é a única opção nessa situação), antes do desligamento, a tela preta desaparece por meio segundo e aparece uma tela vermelha (a tela vermelha de slock quando você digita uma senha errada). Então, o slock está realmente rodando. Mas por que a mensagem de erro afirma que dzen e slock "não podem abrir a exibição", enquanto na verdade estão sendo executados? E por que a tela falha? E de que maneira a mensagem de erro xset é diferente?
Uma alternativa cherry_keyboard.sh :
#!/bin/bash
exec >>/home/*user*/.udev_rule_scripts/test.log 2>&1; echo; date
export DISPLAY=:0
export XAUTHORITY=/home/*user*/.Xauthority
echo 'test' | dzen2 -p 4
su *user* -c "DISPLAY=:0 xset r rate 150 60"
#su *user* -c "DISPLAY=:0 slock"
test.log :
Tue Feb 23 10:43:36 UTC 2016
Portanto, desta vez não há mensagens de erro.
Mas, em ambas as versões, xset não modifica a repetição automática ...
Para começar, suas diretivas correspondentes estão seriamente erradas: uma regra melhor deve corresponder apenas ao SUBSYSTEM e ao USB VID e PID.
De qualquer forma, você não pode ter apenas comandos root run que devem controlar sua sessão X ativa. Se você realmente tem que fazer isso, então você deve no mínimo importar $ DISPLAY e $ XAUTHORITY, mas a solução correta é usar as ferramentas nativas do seu ambiente de desktop para executar esses comandos quando apropriado.
Scripts executados a partir do udev são executados em um ambiente quase vazio. Eles não estão ligados a nenhuma sessão ou terminal em particular.
A primeira coisa que você precisa fazer é ler as mensagens de erro. Adicione exec >>/var/log/my-udev-script.log 2>&1; echo; date no início do seu script logo abaixo da linha #! e dê uma olhada em /var/log/my-udev-script.log depois que o script for acionado.
O comando xset é um cliente X Window System , então ele precisa falar com um servidor X . Ele sabe com qual servidor X conversar (pode haver muitos) a partir do valor da variável de ambiente DISPLAY . Se DISPLAY não estiver definido, xset não pode falar com nenhum servidor X, então tudo o que ele faz é imprimir uma mensagem de erro e sair.
Para descobrir como definir DISPLAY e XAUTHORITY , se necessário, consulte e Abra uma janela em um display X remoto (por que" Cannot open display " ) Note que pode ser difícil descobrir o que fazer se houver vários servidores X.
Nem o xset nem o slock precisam ou se importam com o D-Bus. Se você realmente precisa do D-Bus, Como iniciar o dbus com um endereço fixo? é o caminho mais fácil de seguir.