Eu não tenho o hadware exato, mas tentei encontrar um "caso semelhante" no meu sistema:
-
Um era o botão de energia. O objetivo é inserir uma chave (por exemplo, tecla "4") em vez de poder. (para mim, ele fica em / dev / input / event2 e emite um
root# evtest /dev/input/event2
Event: time 1509218410.222521, type 1 (EV_KEY), code 116 (KEY_POWER), value 1
Event: time 1509218410.222521, -------------- SYN_REPORT ------------
Event: time 1509218410.222552, type 1 (EV_KEY), code 116 (KEY_POWER), value 0
Event: time 1509218410.222552, -------------- SYN_REPORT ------------ -
O outro é (é por isso que eu estou interessado em soo profundamente): Eu também tenho um botão WIFI, mas "não faz nada". Embora eu entenda eventos de entrada, quero corrigir isso - por diversão. Aqui o alvo é fazer algo.
Este Fn + F3 emite (do dispositivo de entrada de teclado normal)
root# evtest /dev/input/event3
Event: time 1509218870.384483, type 4 (EV_MSC), code 4 (MSC_SCAN), value 86
Event: time 1509218870.384483, -------------- SYN_REPORT ------------
Esta Fn + F3 originou originalmente uma linha de aviso no syslog
kernel: [44802.485207] atkbd serio0: Unknown key released (translated set 2, code 0x86 on isa0060/serio0).
kernel: [44802.485210] atkbd serio0: Use 'setkeycodes e006 ' to make it known.
O que eu fiz até agora:
- executa muitas séries de setkeycodes
Nemevdevnem "vida real" viram alterações, mas comsetkeycodes e006 5ousetkeycodes 86 5a entrada do syslog foi eliminada. -
criou o arquivo hwdb em / etc / udev / hwdb semelhante como - isso eliminou a mensagem do syslog também - MAS NÃO FUI NADA MAIS:
evdev:atkbd:dmi:bvn*:bvr*:bd*:svn*:pn*:pvr*
KEYBOARD_KEY_86=5 -
criou a regra do udev em /etc/udev/rules.d (e fez efeito)
ele é executado (porque eu vejo o "botão INIBIR cadeia de energia" e ver todas as marcas modificadas), eu posso mudar qualquer atributo (jogado principalmente para o botão de energia)
Aqui está o meu arquivo de regras:ACTION!="add|change", GOTO="pwr_kbd_end"
SUBSYSTEM!="input", GOTO="pwr_kbd_end"
KERNEL!="event[0-9]*", GOTO="pwr_kbd_end"
ENV{ID_PATH_TAG}=="acpi-LNXPWRBN_00", OPTIONS+="last_rule", RUN+="/usr/bin/logger -t Power button INHIBIT %k", ENV{KEYBOARD_KEY_116}="KEY_A",\ TAG:="whatisthis", ENV{EV_KEY_116}="KEY_B", \ ENV{BTN_116}="KEY_C",ENV{BTN_POWER}="KEY_D", ENV{KEY_POWER}="KEY_E" LABEL="pwr_kbd_end"No entanto, li e percebi que as regras são para "alterações no sistema", como conectar ou desconectar algo, modificar (como criar uma nova partição ou brincar com modangle 3G dongles), mas elas não têm nada a ver com o tratamento real do evento principal (no entanto eles poderiam ter influência). Enquanto isso,
OPTIONS+="last_rule"parece não estar funcionando - eu entrei neste arquivo como 01-myrule.rule e como link duro 98-myrule.rule - ambos estão "trabalhando". -
Depois, concentrei meu interesse em lidar com os eventos:
Eu copiei um scriptevtest.pypython e toquei um pouco.
Meu conceito era "interceptar o evento power putton, não passar e injetar outro (por exemplo, KEY_4 - value 5 - como tentei em meus testes anteriores).
Isso foi quase total sucesso. (esta também pode ser a sua solução)
from __future__ import print_function import sys import select from evdev import ecodes, list_devices, AbsInfo, InputDevice, UInput def main(): device = InputDevice("/dev/input/event2") # yours should be checked... NOT necessalirly always event8 device.grab() ui = UInput() print('Listening for events (press ctrl-c to exit) ...') fd_to_device = {device.fd: device} while True: r, w, e = select.select(fd_to_device, [], []) for fd in r: for event in fd_to_device[fd].read(): if (event.type == 1) and (event.code==116): # yours is 238 print_event(event) event.code=5 event.value=1 ui.write(event.type, event.code, event.value) # just delete/comment this section if you do not wanna do anything ui.syn event.value=0 ui.write(event.type, event.code, event.value) ui.syn else: ui.write(event.type, event.code, event.value) ui.syn def print_event(e): if e.type == ecodes.EV_SYN: if e.code == ecodes.SYN_MT_REPORT: msg = 'time {:<16} +++++++++ {} ++++++++' else: msg = 'time {:<16} --------- {} --------' print(msg.format(e.timestamp(), ecodes.SYN[e.code])) else: if e.type in ecodes.bytype: codename = ecodes.bytype[e.type][e.code] else: codename = '?' evfmt = 'time {:<16} type {} ({}), code {:<4} ({}), value {}' print(evfmt.format(e.timestamp(), e.type, ecodes.EV[e.type], e.code, codename, e.value)) if __name__ == '__main__': try: ret = main() except KeyboardInterrupt: ret = 0 sys.exit(ret)
Mais uma vez, não importa se estou no console ou no X - quando esse script está em execução, obtenho uma chave (atualmente é de alguma forma duvidosa) em vez de "alternar energia".
- Eu interceptei (mas deixei eles passarem pelos eventos do teclado) e quando encontrei meu código mágico 86, injetei uma seqüência EV_KEY (EV_KEY KEY_4 para baixo, SYN, EV_KEY KEY_4 para cima, SYN)
Isso é um sucesso parcial, no entanto, porque os eventos de alguma forma ficaram presos e esperaram um pelo outro e eles apareceram como um monte de 4 (eu usei python -u wifi.py) - então eu tento ficar sem buffer. Aqui não há duvida: eu pressiono o botão Wifi 4 vezes, recebo '4444' - no console, assim como no X.