Как в ядре Linux обрабатывается нажатие на клавиатуру?

Пока ваше понимание правильное, но вы упускаете большую часть сложности, которая на этом построена. Обработка в ядре происходит на нескольких уровнях, и нажатие клавиши «пузырится» по слоям.

Сам протокол связи USB гораздо сложнее. Процедура обработки прерывания для USB обрабатывает это и, при необходимости, собирает полный пакет USB из нескольких фрагментов.

Нажатие клавиши использует так -называемый HID("устройство интерфейса пользователя" ), который построен поверх USB. Таким образом, нижний уровень ядра USB определяет, что полное сообщение является событием USB HID, и передает его на уровень HID в ядре.

Уровень HID интерпретирует это событие в соответствии с дескриптором HID, который требуется от устройства при инициализации. Затем он передает события входному слою. Одно HID-событие может генерировать несколько событий нажатия клавиш.

Уровень ввода использует таблицы раскладки клавиатуры ядра для сопоставления кода сканирования (положения клавиши на клавиатуре )с кодом клавиши (, например A), и интерпретирует Shift , Alt и т. д. Результат этой интерпретации становится доступным через /dev/input/event*для пользовательских процессов. Вы можете использовать evtestдля наблюдения за этими событиями в реальном -времени.

Но обработка здесь не закончена. X-сервер (, отвечающий за графику ), имеет универсальный evdevдрайвер, который считывает события с /dev/input/event*устройств, а затем снова отображает их в соответствии со вторым набором таблиц раскладки клавиатуры (. ] вы можете увидеть их частично с помощью xmodmapи полностью с помощью расширения XKBD ). Это связано с тем, что X-сервер предшествует уровню ввода ядра, и в прежние времена у него были драйверы для прямой обработки мыши и клавиш PS/2.

Затем X-сервер отправляет сообщение X-клиенту (приложению ), содержащее событие клавиатуры. Вы можете просмотреть эти сообщения с помощью приложения xev. LibreOfficeбудет обрабатывать это событие напрямую, VIMбудет выполняться в xterm, который будет обрабатывать событие, и (как вы уже догадались )снова добавить к нему дополнительную обработку и, наконец, передать его VIMчерез stdin.

Достаточно сложно?

does it simply write the pressed key into a buffer (available through a char-device?)

Да, я должен сказать.

И затем есть своего рода каскад от (низкоуровневой )консоли к tty (виртуальному )к псевдо -tty. Нажатие клавиши записывается в /dev/tty1 или /dev/tty5 в зависимости от того, какая «консоль» активна.

А в xterm (вывод ps axf):

  467 tty1     Ss     0:38  \_ -bash
 5820 tty1     S+     0:00      \_ xinit fvwm -- vt9
 5821 tty9     S<sl+  54:15          \_ /usr/lib/Xorg :0 vt9
 5831 tty1     S      0:00          \_ xterm -geometry +1+1 -n login fvwm
 5833 pts/0    Ss+    0:38              \_ fvwm
...
...
  773 pts/0    S      0:07                  \_ xterm
  775 pts/2    Ss+    0:00                  |   \_ bash
14452 pts/0    S      0:04                  \_ xterm
14454 pts/1    Ss     0:00                  |   \_ bash
14507 pts/1    S      0:00                  |       \_ xfontsel
31044 pts/1    R+     0:00                  |       \_ ps ax f
19549 pts/0    S      0:00                  \_ xterm
19551 pts/3    Ss+    0:00                      \_ bash

Это показывает, как Xorg запускается на tty9 с tty1, и как fvwm (оконный менеджер )и xterm (эмулятор терминала )"берут" /dev/pts/0, и это новый оболочки, получающие /dev/pts/1, pts/2. пц/3 и так далее.

Теперь, независимо от того, активирую ли я этот bash-процесс pid 19551 pts/3, указав на его окно xterm, а затем нажму клавишу, или если я сделаю echo hello >/dev/pts/3из консоли, например / dev/tty5 символы переходят к правильному процессу.

man psхорошо объясняет (, он перечисляет их )в разделе КОДЫ СОСТОЯНИЯ ПРОЦЕССА:

S    interruptible sleep (waiting for an event to complete)
s    is a session leader    
+    is in the foreground process group

Я оставляю вас с этими ключевыми словами...