it-swarm-pt.com

Como depurar a entrada de um dispositivo de entrada (/ dev / input / event *)

Eu tenho um receptor de IR que está usando o imon-driver e gostaria de fazê-lo funcionar com o kernel. No momento, metade das teclas no controle remoto ( imagem ) funciona, mas um pensamento muito importante, como as teclas numéricas, não!

O pensamento estranho é que o módulo de mapa de teclas do kernel (rc-imon-pad) parece estar correto, mas parece que não é realmente usado, pois exatamente as mesmas chaves estão trabalhando sem esse módulo.

Parece que o módulo rc-imon-pad sempre é carregado quando carrego o imon e, em seguida, suspeito que os códigos de chave estão armazenados em cache, para que não faça diferença se eu descarregar o rc-imon-pad

Agora estou perdido, se eu fizer cat /dev/input/event5 ou ir-keytable -t existem dados, não importa a tecla que eu pressione, então o driver registra os botões, mas parece que eles estão traduzidos para os códigos de teclas errados.

Meus kernels são um kernel de estoque do ubuntu da Natty (Linux xbmc 2.6.37-11-generic # 25-Ubuntu SMP terça-feira, 21 de dezembro às 23:42:56 UTC 2010 x86_64 GNU/Linux)

19
LassePoulsen

Eu tenho o mesmo controle remoto e o envio de códigos de chave corretos para o meu kernel 2.6.38-gentoo-r3. Eu não compilei códigos de chave como um módulo, porque eles provavelmente ainda não tiveram tempo para possibilitar a seleção de mapas de teclas individuais ainda. É tudo ou nada e eu não gosto de um bilhão de módulos inúteis me entulhando. Em vez disso, estou deixando o v4l-utils lidar com isso com o udev.

Aprendi algumas coisas:

  • Verifique a saída do ir-keytable -r, ele deve listar todos os códigos de tecla aplicáveis no seu controle remoto.
  • Carregue a tabela de teclas manualmente: ir-keytable -c -w bleh/keymaps/imon_pad, após o qual a ir-keytable -r deve devolver a tabela
  • Você pode realmente ter um receptor com defeito, não menciona nada sobre a história. Lembro-me de ter visto pelo menos uma mensagem em lirc-list onde o cara disse enviando o caso de volta e recebendo um novo, resolvendo seus problemas.

Deixe-nos saber como foi.

3
lkraav

Você pode achar útil xinput list e xinput test <device>.

Por exemplo,

 $ xinput list 
 id ID do ponteiro do núcleo virtual = 2 [ponteiro mestre (3)] 
 ⎜ ↳ ID do ponteiro do núcleo virtual XTEST = 4 [ponteiro escravo (2)] 
 ⎜ ↳ ID do TouchPad SynPS/2 Synaptics = 11 [ponteiro escravo (2)] 
 Id ID do teclado do núcleo virtual = 3 [teclado principal (2)] 
 Id ID do teclado do núcleo virtual XTEST = 5 [teclado escravo (3)] 
 Id Identificação do botão liga/desliga = 6 [teclado escravo (3)] 
 Id ID do barramento de vídeo = 7 [teclado escravo (3)] 
 ↳ ID do botão de suspensão = 8 [teclado escravo (3)] 
 Buttons ID dos botões extras do laptop Asus = 9 [teclado escravo (3)] 
 ↳ AT Traduzido Defina 2 id do teclado = 10 [teclado secundário (3)] 

e eu posso monitorar meu teclado (xinput test 10) ou touchpad (xinput test 11, ou mesmo xinput test "SynPS/2 Synaptics TouchPad") para todos os tipos de eventos de entrada, e eles são bem impressos no console, e os parâmetros também são extraídos e impressos.

Isso não resolverá seu problema, mas pelo menos ajudará um pouco decifrando a desordem que, por exemplo, cat /dev/input/event1 produz.

17
ulidtko