Kernel Linux descartando códigos de verificação de teclado personalizados

Eu tenho um teclado IBM 122 de modelo-chave vintage M que estou adaptando para uso em um computador moderno. Estou usando um Teensy 2.0 para fazer a codificação e lidar com o lado USB das coisas. Peguei emprestado o firmware do projeto de teclado do Humble Hacker ( https://github.com/humblehacker/keyboard ) e adicionei as chaves extras na configuração da compilação. Por enquanto, tudo bem.

Todas as chaves "regulares" funcionam, mas o kernel parece estar descartando as chaves extras ( F13- F24, etc.).

A execução /lib/udev/keymap -i input/event0mostra os códigos de verificação de todas as teclas normais, mas nada para as teclas extras.

Correr wiresharkpara capturar pacotes na porta USB mostra que o teclado está enviando os códigos de verificação, mas parece que o kernel os está descartando por princípio.

Eu sinto que isso é algo nos drivers do kernel que simplesmente não está fornecendo códigos de verificação que ele não espera.

Eu pensaria que haveria algum tipo de mapa-chave "mestre" em algum .harquivo na fonte do kernel em algum lugar, mas até agora, não tive êxito em meus esforços para encontrá-lo.

Vale ressaltar que não estou perguntando sobre o mapeamento de chaves extras em X, como tantas outras antes de mim. Este é um problema de baixo nível, aparentemente relacionado ao kernel. Suponha, por enquanto, que eu não usarei o X. O que eu preciso é que os códigos de verificação apareçam quando eu corro /lib/udev/keymap -i, posso fazer o resto a partir daí.

— user2543941
fonte

Sei que isso não ajuda, mas: Por que você está usando o Teensy? Esse teclado deve funcionar com um adaptador PS2 / USB direto.

— 10289 goldilocks

O teclado veio de um antigo terminal IBM, não usa um protocolo compatível com PS / 2.

— user2543941

Uau. De fato, pode ser que o motorista não esteja passando o evento adiante (veja a última parte aqui ). Você pode tentar, em evtestvez de /lib/udev/keymap -i, não sei se isso será diferente.

— Goldilocks

O evtest também não mostra nada quando as teclas extras são usadas.

— user2543941

Parece que, se você quiser usar essas teclas, seu projeto ficará um pouco maior, lol. A coisa mais difícil de escrever um driver de teclado será aprender a API, caso contrário eles não parecerão tão complicados. Não faço nenhum kernel há algum tempo, mas isso: LDD3 ainda é válido para 3.x, eu acho.

— Goldilocks

Respostas:

O kernel vê os códigos de verificação estranhos e os descarta. Eu tentaria obter esses valores dos códigos de verificação e atualizar o índice do banco de dados de hardware. Então, resumindo, o plano é o seguinte:

obtenha os códigos da saída dmesg - o dmesg deve gerar algo assim quando o código de tecla desconhecido for pressionado:
```
Unknown key pressed (translated set 2, code 0xa0 on isa0060/serio0)
```

a0 sendo o valor do código.

crie um arquivo de mapeamento de código de chave personalizado. Os exemplos e a ajuda estão no arquivo padrão
( /usr/lib/udev/hwdb.d/60-keyboard.hwdbpara o Arch, pode ser diferente em outras distribuições).
atualize e acione o banco de dados de hardware executando os comandos:
```
> udevadm hwdb --update
> udevadm trigger /dev/input/eventXX
```

onde eventXXcorresponde ao seu teclado (você pode obtê-lo executando evtest). Você também pode reiniciar em vez de acionar.

Procure no Arch wiki e no arquivo de mapeamento de código de chave padrão para obter uma descrição mais detalhada (ou na documentação de distribuição, se não for Arch).

Este é o método confiável e simples, faz o mapeamento no nível do kernel para funcionar com qualquer servidor de exibição, DE etc.

— xbob
fonte

Este site oferece conversões personalizadas de teclado http://straypoetry.com/ibm-model-m-keyboard/

Com base nas informações deste site: http://deskthority.net/workshop-f7/xt-at-ps2-terminal-to-usb-converter-with-nkro-t2510.html

— marca
fonte