Noyau Linux supprimant des codes de numérisation de clavier personnalisés

16

J'ai un clavier IBM 122 touches modèle M vintage que j'adapte pour une utilisation sur un ordinateur moderne. J'utilise un Teensy 2.0 pour faire l'encodage et gérer le côté USB des choses. J'ai emprunté le firmware du projet de clavier Humble Hacker ( https://github.com/humblehacker/keyboard ) et j'ai ajouté les touches supplémentaires dans la configuration de construction. Jusqu'ici tout va bien.

Toutes les clés "normales" fonctionnent, mais le noyau semble supprimer les clés supplémentaires ( F13- F24, etc.).

Running /lib/udev/keymap -i input/event0montre les codes de scan de toutes les clés normales, mais rien pour les clés supplémentaires.

L'exécution wiresharkde la capture de paquets sur le port USB montre que le clavier envoie les codes de numérisation, mais il semble que le noyau les supprime simplement par principe.

J'ai l'impression que c'est quelque chose dans les pilotes du noyau qui ne fournit tout simplement pas de codes de numérisation auxquels il ne s'attend pas.

Je pense qu'il y aurait une sorte de mappage de clé "maître" dans un .hfichier de la source du noyau quelque part, mais jusqu'à présent, je n'ai pas réussi à le trouver.

Il convient de souligner que je ne demande pas de mapper les clés supplémentaires dans X, comme tant d'autres avant moi. Il s'agit d'un problème de bas niveau, apparemment lié au noyau. Supposons pour le moment que je n'utiliserai pas du tout X. Ce dont j'ai besoin, c'est que les codes de numérisation apparaissent lorsque je cours /lib/udev/keymap -i, je peux faire le reste à partir de là.

linux kernel linux-kernel keyboard-shortcuts keyboard user2543941
la source
Je sais que cela n'aide pas mais: Pourquoi utilisez-vous le Teensy? Ce clavier devrait fonctionner avec un adaptateur PS2 / USB droit.
goldilocks
Le clavier provient d'un ancien terminal IBM, il n'utilise pas de protocole compatible PS / 2.
user2543941
Sensationnel. Il se pourrait en effet que le pilote ne passe pas l'événement (regardez la dernière partie ici ). Vous pouvez essayer evtestau lieu de /lib/udev/keymap -i, ne sais pas si cela sortira différemment.
goldilocks
1
evtest n'affiche également rien lorsque les touches supplémentaires sont utilisées.
user2543941
1
On dirait que si vous voulez utiliser ces touches, votre projet est devenu un peu plus gros, lol. La chose la plus difficile à écrire sur un pilote de clavier sera d'apprendre l'API, sinon ils n'auront pas l'air si compliqués. Je n'ai rien fait de noyau depuis un moment, mais ceci: LDD3 est toujours valide pour 3.x, je pense.
goldilocks

Réponses:

1

Le noyau voit les codes d'analyse étranges et les supprime. J'essaierais d'obtenir ces valeurs de codes de numérisation, puis de mettre à jour l'index de la base de données matérielle. Bref, le plan est le suivant:

  • obtenir les codes de la sortie dmesg - dmesg devrait sortir quelque chose comme ceci lorsque le code clé inconnu est pressé:

    Unknown key pressed (translated set 2, code 0xa0 on isa0060/serio0)

a0 étant la valeur de code.

  • créer un fichier de mappage de codes clés personnalisé. Les exemples et l'aide se trouvent dans le fichier par défaut
    (/usr/lib/udev/hwdb.d/60-keyboard.hwdb pour Arch, il peut être différent dans d'autres distributions).

  • mettre à jour et déclencher la base de données matérielle en exécutant les commandes:

    > udevadm hwdb --update
> udevadm trigger /dev/input/eventXX

où eventXX correspond à votre clavier (vous pouvez l'obtenir en exécutant evtest). Vous pouvez également redémarrer au lieu de déclencher.

Regarder dans wiki d'Arch et le fichier de mappage de code clé par défaut pour la description plus détaillée (ou dans votre documentation de distribution si ce n'est pas Arch).

C'est la méthode fiable et simple qui rend le mappage au niveau du noyau fonctionne donc quel que soit le serveur d'affichage, DE, etc.

xbob
la source