/ dev / input - O que exatamente é isso?

Fiquei curioso sobre como o hardware interagia com o sistema operacional e me deparei com este post: Como a entrada do teclado e a saída de texto funcionam?

Parece que muita mágica acontece no diretório / dev / input. Decidi dar uma olhada no meu próprio sistema operacional (Ubuntu 16.10) para ver o que eu poderia descobrir. Todos esses arquivos estão listados como 0 bytes, e quando sudo cat mouse0 | hexdump -Ceu recebo uma tonelada de hexdata que se parece com isso:

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..............|

Então, eu tenho algumas perguntas:

Qual é o objetivo deste arquivo? Parece-me que esses arquivos de dispositivo são usados apenas como intermediários para transferir o scancode do kernel para o servidor X. Por que não apenas enviá-lo diretamente do kernel para o servidor X?
Por que existem tantos? Tenho um pouco mais de 20 arquivos de eventos individuais, mas apenas um teclado e mouse.

linux devices

— Astrum
fonte

Eu vou com a pergunta na ordem inversa:

Por que existem tantos?

Esses são os dispositivos que representam a maioria das entradas presentes em uma máquina (existem outros, um microfone, por exemplo, não será gerenciado /dev/input). Ao contrário da suposição de que um teclado mais um mouse forneceria 2 dispositivos, mesmo o teclado mais simples e o mouse mais simples ainda forneceriam 6 deles.

Por que 6? Porque o Xorg criará um teclado de entrada de teste e um mouse de entrada de teste (ambos virtuais) durante sua inicialização. Além disso, ele agregará o teclado de teste com o teclado real em um dispositivo virtual principal. ou seja, ele executará o muxing da entrada. O mesmo acontecerá com o teste e o mouse real.

Além disso, um computador típico (desktop ou laptop) possui outros botões além do teclado: botão liga / desliga, botão de suspensão.

Os eventNdispositivos lá são dispositivos para as coisas que o Xorg cria e para o que o computador possui. O Nvem de IDs seqüenciais e é análogo aos IDs em xinput. Por exemplo, na minha máquina, tenho:

[~]# 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 xinputme fornece IDs análogos:

[~]$ 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)]

(Veja que eventNcorresponde a id=N)

Sem o Xorg

1.1 Qual é o objetivo deste arquivo?

Observe que todas as entradas aleatórias (incluindo minha câmera USB!) São vistas pelo Xorg como parte do teclado virtual. Isso permite a entrada de muxing e desmuxing. Por exemplo, posso mover o mouse pelo mouse USB ou pelo trackpad e um aplicativo não precisa saber a diferença.

(O fato de a câmera USB fazer parte do teclado virtual é porque ela possui um botão para ligá-lo e desligá-lo. E como é um botão, ela se torna parte do subsistema do teclado. A entrada de vídeo real é manipulada /sys/class/video4linux. )

Em outras palavras, para um aplicativo, existe realmente apenas um teclado e apenas um mouse. Mas o Xorg e o kernel precisam saber as diferenças. E isso leva à última parte:

1.2 Por que não apenas enviá-lo diretamente do kernel para o servidor X?

Porque o Xorg precisa saber a diferença.

E há situações em que é útil. Você pode remapear as chaves no Xorg para cada dispositivo de entrada escravo de maneira diferente. Por exemplo, eu tenho um conjunto de jogos com pedais, quando usados em um jogo de corrida ele produz a, be cpara cada um de seus pedais. No entanto, quando a programação I remapear essas chaves para Esc, Ctrle Alt, sem remapeamento as chaves no próprio teclado.

Além disso, não é necessário que uma máquina execute o Xorg. Por exemplo, em um servidor sem cabeça, posso obter a seguinte saída:

[~]$ 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

Onde os dispositivos de entrada correspondem às portas seriais (principalmente nesse caso), em vez do teclado ou mouse.

— grochmal
fonte

O próprio suporte da câmera (como na recuperação de vídeo) não passa pelo subsistema de entrada, mas pelo V4L2. As câmeras são dispositivos de teclado de entrada, porque às vezes eles têm botões, e aqueles agir como chaves ...

— Stephen Kitt

@StephenKitt - Uau, sim. Eu nunca me intrometi com o subsistema de câmera, mas agora posso ver / sys / class / video4linux. Existem algumas interfaces interessantes lá. Obrigado pela informação! (Atualizei o asnwer e removi a parte enganosa).

— precisa saber é o seguinte

O Xorg não cria arquivos de dispositivo: não é um driver. Em vez disso, abre-os e executa o IO através deles. Torna-se realmente óbvio quando você inicia a máquina sem o X e ainda vê esses dispositivos (e pode executar, por exemplo gpm).

— Ruslan

@Ruslan Por que eu precisaria de um driver para criar arquivos de dispositivo? Eu posso criar um dispositivo de bloco usando uma montagem em loop, por exemplo. Os dispositivos ainda estariam lá sem o X, mas os arquivos reais do dispositivo (nos kernels modernos) não. X vai usar udev bem, mas as regras do udev para um mouse, por exemplo, não será executada se a inicialização sem X.

— grochmal

Acabei de rodar o Ubuntu 18.04 Live sem lançar o X. Ainda vejo esses arquivos. Mais uma vez: o mouse pode funcionar sem o X, veja, por exemplo, o gpmdaemon ou GTK2 no framebuffer.

— Ruslan

Não existe algo como "envie diretamente". Os aplicativos devem ter algum método de leitura dos dados e, no unix, da mesma maneira que leem os arquivos regulares, criando um nó de dispositivo que funciona com as chamadas normais do sistema de E / S de arquivos para permitir que os aplicativos os abram e os leiam.

Existem outras fontes de entrada além do mouse e teclado. Você pode descobrir o que cada um é olhando /sys/class/input. Lá, você encontrará arquivos com os mesmos nomes inputNN que são links simbólicos para outro nó no sysfs que descreve o dispositivo que eles representam. Outras fontes comuns incluem placas de som (que sinalizam quando coisas são conectadas e desconectadas) e o botão de energia físico no computador.

— psusi
fonte