Il kernel Linux elimina i codici di scansione della tastiera personalizzati


16

Ho una tastiera vintage modello IBM 122 chiave M che sto adattando per l'uso su un computer moderno. Sto usando un Teensy 2.0 per fare la codifica e per gestire il lato USB delle cose. Ho preso in prestito il firmware dal progetto della tastiera Humble Hacker ( https://github.com/humblehacker/keyboard ) e ho aggiunto le chiavi extra nella configurazione della build. Fin qui tutto bene.

Tutte le chiavi "normali" funzionano, ma sembra che il kernel stia rilasciando le chiavi extra ( F13- F24, ecc.).

L'esecuzione /lib/udev/keymap -i input/event0mostra i codici di scansione di tutti i tasti normali, ma nulla per i tasti extra.

In esecuzione wiresharkper l'acquisizione di pacchetti la porta USB mostra che la tastiera sta inviando i codici di scansione, ma sembra che il kernel li stia semplicemente abbandonando per principio.

Sento che questo è qualcosa nei driver del kernel che semplicemente non sta fornendo codici di scansione che non si aspetta.

Penserei che da qualche parte ci sarebbe una sorta di mappa di chiavi "master" in qualche .hfile nel sorgente del kernel, ma finora non ho avuto successo nei miei sforzi per trovarla.

Vale la pena sottolineare che non sto chiedendo di mappare i tasti extra in X, come tanti altri prima di me. Questo è un problema di basso livello, apparentemente correlato al kernel. Supponiamo per il momento che non userò affatto X. Ciò di cui ho bisogno è che i codici di scansione vengano visualizzati quando corro /lib/udev/keymap -i, posso fare il resto da lì.


So che questo non aiuta ma: perché stai usando Teensy? Quella tastiera dovrebbe funzionare con un adattatore PS2 / USB dritto.
Riccioli d'oro,

La tastiera proviene da un vecchio terminale IBM, non utilizza un protocollo compatibile PS / 2.
user2543941

Wow. Potrebbe davvero essere che il guidatore non stia trasmettendo l'evento (dai un'occhiata all'ultima parte qui ). Potresti provare evtestinvece /lib/udev/keymap -i, non so se ne uscirà diverso.
Riccioli d'oro,

1
evtest inoltre non mostra nulla quando vengono utilizzati i tasti extra.
user2543941

1
Sembra che se vuoi usare quelle chiavi il tuo progetto è diventato un po 'più grande, lol. La cosa più difficile nello scrivere un driver di tastiera sarà l'apprendimento dell'API, altrimenti non sembrano così complicati. Non ho fatto nulla del kernel da un po 'di tempo, ma questo: LDD3 è ancora valido per 3.x, credo.
Riccioli d'oro,

Risposte:


1

Il kernel vede gli strani codici di scansione e li rilascia. Vorrei provare a ottenere quei valori dei codici di scansione e quindi aggiornare l'indice del database hardware. Quindi in breve il piano è questo:

  • ottenere i codici dall'output di dmesg - dmesg dovrebbe produrre qualcosa del genere quando viene premuto il codice chiave sconosciuto:

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

a0 essendo il valore del codice.

  • creare un file di mappatura del codice chiave personalizzato. Gli esempi e la guida si trovano nel file predefinito
    ( /usr/lib/udev/hwdb.d/60-keyboard.hwdbper Arch, potrebbe essere diverso in altre distribuzioni).

  • aggiorna e attiva il database hardware eseguendo i comandi:

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

dove eventXXcorrisponde alla tua tastiera (puoi ottenerlo eseguendo evtest). È inoltre possibile riavviare invece di eseguire il trigger.

Cerca in Arch wiki e nel file di mappatura del codice tasto predefinito per la descrizione più dettagliata (o nella documentazione di distribuzione se non è Arch).

Questo è il metodo affidabile e semplice, rende la mappatura a livello di kernel in modo che funzioni qualunque sia il display server, DE ecc.


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.