/ dev / input - Cos'è esattamente questo?


12

Ero curioso di sapere come l'hardware interagiva con il sistema operativo e mi sono imbattuto in questo post: come funzionano l'input da tastiera e l'output di testo?

Sembra che molta della magia avvenga nella directory / dev / input. Ho deciso di dare un'occhiata al mio sistema operativo (Ubuntu 16.10) per vedere cosa avrei potuto scoprire. Tutti questi file sono elencati come 0 byte e quando lo faccio sudo cat mouse0 | hexdump -Cottengo un sacco di hexdata che assomigliano a questo:

00000000  b3 82 8a 58 00 00 00 00  53 74 09 00 00 00 00 00  |...X....St......|
00000010  01 00 1c 00 00 00 00 00  b3 82 8a 58 00 00 00 00  |...........X....|
00000020  53 74 09 00 00 00 00 00  00 00 00 00 00 00 00 00  |St..............|
00000030  b6 82 8a 58 00 00 00 00  06 56 0e 00 00 00 00 00  |...X.....V......|
00000040  01 00 10 00 01 00 00 00  b6 82 8a 58 00 00 00 00  |...........X....|
00000050  06 56 0e 00 00 00 00 00  00 00 00 00 00 00 00 00  |.V..............|

Quindi ho alcune domande:

  1. Qual è lo scopo di questo file? Mi sembra che questi file di dispositivo vengano usati solo come intermediari per trasferire lo scancode dal kernel al server X. Perché non inviarlo direttamente dal kernel al server X?

  2. Perché ce ne sono così tanti? Ho poco più di 20 singoli file di eventi, ma solo una tastiera e un mouse.

Risposte:


17

Vado con la domanda in ordine inverso:

  1. Perché ce ne sono così tanti?

Questi sono dispositivi che rappresentano la maggior parte degli ingressi presenti su una macchina (ce ne sono altri, ad esempio un microfono non verrà gestito /dev/input). Contrariamente al presupposto che una tastiera più un mouse darebbero 2 dispositivi, anche la tastiera più semplice e il mouse più semplice ne darebbero ancora 6.

Perché 6? Perché Xorg creerà una tastiera di input di test e un mouse di input di test (entrambi virtuali) durante l'avvio. Inoltre, aggregherà la tastiera di test con la tastiera effettiva in un dispositivo virtuale principale. cioè eseguirà il muxing dell'input. Lo stesso accadrà al test e al mouse attuale.

Inoltre un tipico computer (desktop o laptop) ha altri pulsanti oltre alla tastiera: pulsante di accensione, pulsante di sospensione.

I eventNdispositivi lì dentro sono dispositivi per le cose che Xorg crea e per ciò che il computer ha. La Nderiva dagli ID sequenziali ed è analogo agli ID di xinput. Ad esempio sulla mia macchina ho:

[~]# ls -l /dev/input/
total 0
drwxr-xr-x 2 root root     100 Jan 26 16:01 by-id
drwxr-xr-x 2 root root     140 Jan 26 16:01 by-path
crw-rw---- 1 root input 13, 64 Jan 26 16:01 event0
crw-rw---- 1 root input 13, 65 Jan 26 16:01 event1
crw-rw---- 1 root input 13, 74 Jan 26 16:01 event10
crw-rw---- 1 root input 13, 75 Jan 26 16:01 event11
crw-rw---- 1 root input 13, 76 Jan 26 16:01 event12
crw-rw---- 1 root input 13, 77 Jan 26 16:01 event13
crw-rw---- 1 root input 13, 66 Jan 26 16:01 event2
crw-rw---- 1 root input 13, 67 Jan 26 16:01 event3
crw-rw---- 1 root input 13, 68 Jan 26 16:01 event4
crw-rw---- 1 root input 13, 69 Jan 26 16:01 event5
crw-rw---- 1 root input 13, 70 Jan 26 16:01 event6
crw-rw---- 1 root input 13, 71 Jan 26 16:01 event7
crw-rw---- 1 root input 13, 72 Jan 26 16:01 event8
crw-rw---- 1 root input 13, 73 Jan 26 16:01 event9
crw-rw---- 1 root input 13, 63 Jan 26 16:01 mice
crw-rw---- 1 root input 13, 32 Jan 26 16:01 mouse0
crw-rw---- 1 root input 13, 33 Jan 26 16:01 mouse1

E xinputmi dà ID analoghi:

[~]$ xinput list
⎡ Virtual core pointer                      id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ Logitech USB Optical Mouse                id=10   [slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad                id=14   [slave  pointer  (2)]
⎣ Virtual core keyboard                     id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]
    ↳ Video Bus                                 id=7    [slave  keyboard (3)]
    ↳ Power Button                              id=8    [slave  keyboard (3)]
    ↳ Sleep Button                              id=9    [slave  keyboard (3)]
    ↳ USB 2.0 Camera                            id=11   [slave  keyboard (3)]
    ↳ Asus Laptop extra buttons                 id=12   [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=13   [slave  keyboard (3)]

(Guarda che eventNcorrisponde a id=N)

Senza Xorg

1.1 Qual è lo scopo di questo file?

Nota che tutti gli ingressi casuali (compresa la mia videocamera USB!) Sono visti da Xorg come parte della tastiera virtuale. Ciò consente input di muxing e demuxing. Ad esempio, posso spostare il mouse tramite il mouse USB o il trackpad e un'applicazione non deve conoscere la differenza.

(Il fatto che la videocamera USB faccia parte della tastiera virtuale è perché ha un pulsante per accenderla e spegnerla. E dal momento che è un pulsante, diventa parte del sottosistema tastiera. Viene gestito l'effettivo ingresso video /sys/class/video4linux. )

In altre parole, per un'applicazione esiste davvero solo una tastiera e un solo mouse. Ma sia Xorg che il kernel devono conoscere le differenze. E questo porta all'ultima parte:

1.2 Perché non inviarlo direttamente dal kernel al server X?

Perché Xorg ha bisogno di sapere la differenza.

E ci sono situazioni in cui è utile. È possibile rimappare le chiavi in ​​Xorg su ciascun dispositivo di input slave in modo diverso. Ad esempio, ho un set di gioco con i pedali, quando viene utilizzato in un gioco di corse in output a, be cper ciascuno dei suoi pedali. Eppure, durante la programmazione sono rimappare queste chiavi Esc, Ctrle Altsenza rimappatura i tasti della tastiera stessa.

Inoltre, non è necessario che una macchina esegua Xorg. Ad esempio, su un server senza testa posso ottenere il seguente output:

[~]$ ls -l /dev/input/
total 0
drwxr-xr-x 2 root root      80 Nov  8 02:36 by-path
crw-rw---- 1 root input 13, 64 Nov  8 02:36 event0
crw-rw---- 1 root input 13, 65 Nov  8 02:36 event1
crw-rw---- 1 root input 13, 66 Nov  8 02:36 event2

Laddove i dispositivi di input corrispondono a porte seriali (in particolare in questo caso lo fanno) anziché a tastiera o mouse.


3
Il supporto della fotocamera stessa (come nel recupero di video) non passa attraverso il sottosistema di input, ma tramite V4L2. Le telecamere sono dispositivi di input da tastiera perché a volte hanno pulsanti e si comportano come tasti ...
Stephen Kitt,

@StephenKitt - Wow, sì. Non ho mai interferito con il sottosistema videocamera, ma ora posso vedere / sys / class / video4linux. Ci sono alcune interfacce interessanti lì. Grazie per le informazioni! (Ho aggiornato la risposta e rimosso la parte fuorviante).
grochmal

Xorg non crea file di dispositivo: non è un driver. Invece li apre e fa l'IO attraverso di loro. Diventa davvero ovvio quando avvii la macchina senza X e vedi ancora questi dispositivi (e puoi eseguire ad esempio gpm).
Ruslan,

@Ruslan perché dovrei avere bisogno di un driver per creare i file del dispositivo? Posso creare un dispositivo a blocchi usando ad esempio un attacco ad anello. I dispositivi sarebbero ancora lì senza X ma i file dei dispositivi effettivi (sui kernel moderni) no. X utilizzerà udev bene, ma le regole udev per un mouse, ad esempio, non verranno eseguite se si avvia senza X.
grochmal

Ho appena eseguito Ubuntu 18.04 Live senza avviare X. Riesco ancora a vedere questi file. Ancora una volta: il mouse può funzionare senza X, vedere ad esempio il gpmdemone o GTK2 su framebuffer.
Ruslan,

2

Non esiste "invialo direttamente". Le applicazioni devono disporre di un metodo di lettura dei dati e, in unix, vengono eseguite allo stesso modo in cui leggono i file regolari creando un nodo del dispositivo che funziona con le normali chiamate del sistema IO dei file per consentire alle applicazioni di aprirle e leggerle.

Esistono altre fonti di input oltre al mouse e alla tastiera. Puoi scoprire cosa è ognuno guardando /sys/class/input. Lì troverai file fini con gli stessi nomi inputNN che sono collegamenti simbolici a un altro nodo nel sysfs che descrive il dispositivo che rappresentano. Altre fonti comuni includono schede audio (che segnalano quando le cose sono collegate e scollegate) e il pulsante di accensione fisica sul computer.

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.