本文是 How input works – Keyboard input 的翻译。

在上一篇博客中，原作者解释了KWin中，输入设备是如何打开和处理的。在这篇博文中，我们将仔细关注下键盘设备和键盘事件。

键盘并不总是键盘

在Linux中，键盘是一个非常奇特的设备。你不会只有一个键盘，你肯定会有很多个。很多设备宣称自己是键盘，但是只支持一个键。比如，电源按钮或者带静音按钮、音量加减按钮的外置耳机。从输入系统的角度来看，这些设备也是键盘。

对于KWin，发现真正支持的键盘是很重要的。如果没有一个“真的”键盘连接（或者说开启），我们的虚拟键盘应该自动激活。比如，如果你从平板PC二合一设备上拔了键盘，它应该转换为平板模式，即有虚拟键盘的模式。如果连接上了键盘，虚拟键盘就不是主要的输入设备了。libinput提供了函数来检测键盘支持哪些键。我们使用这个功能来区分不同的键盘类型。

键盘事件

在这里，键盘是最简单的输入设备。libinput仅仅触发一个LIBINPUT_EVENT_KEYBOARD_KEY事件，并包含了被按下或者释放的键。KWin有一个专用线程，用来从libinput读取事件。所以这些事件现在仅仅是放在处理队列中，主线程同时也得到新事件通知。一旦主线程处理事件，事件就被转换成我们的输入重定向类。不管事件是通过哪种源头抵达，所有输入事件都会通过输入重定向。KWin不仅仅支持来自libinput的事件，并且支持嵌套会话(即KWin运行在X11之上，或者在另一个Wayland服务器之上)，还有在集成测试中使用的模拟事件。这意味着一旦事件到达输入重定向，我们基本上就丢失了事件来自哪个设备这些信息。最近，我们扩展了内部API，可以在事件处理函数中包含设备源，这是可选的。可以在调试终端中使用，来显示哪些设备产生了哪些事件。

xkbcommon

现在，一个键的按下、释放事件到达了中心分发方法KeyboardInputRedirection::processKey。第一件也是重要的一件事就是在xbkcommon中更新键盘状态。xkbcommon被用将物理键为事件，转换过程根据键盘布局、键盘状态（比如激活的修饰符）来进行。比如：如果我按下了“y”键（键码是21）并且“Shift”键是按下的状态，在德语键盘布局下，就会创建“Z”按下的事件；但是在英语键盘布局下，它会是“Y”。

在KWin中，我们将所有需要的xkbcommon功能都封装到Xkb类中。这个类追踪活跃的键盘布局、执行键盘布局切换（当布局变换的时候展示OSD）。它知道上一次按键的符号，当前活跃的修饰符和快捷键相关的修饰符。

本文是How input works – creating a Device的翻译。

最近，我(原作者，下同）在KWin/Wayland输入栈上做了一些工作，比如实现了鼠标手势和鼠标限制协议（pointer constraints protocol），并且想写一些系列博客来描述输入事件是如何从设备传递到应用的。在第一篇博文中，我将关注于创建和配置输入设备，以及与此相关的其他事情。

evdev

Linux内核通过evdev API来产生输入事件。如果你对evdev如何工作感兴趣，我推荐你读一读Peter Hutterer写的优秀的博文。对于我们关注的层面来说，输入事件API太底层了，我们仅仅想用对它的一个抽象。

libinput 和设备文件

对输入事件API的抽象叫做libinput。它允许我们得到通知，不论何时添加、删除输入设备、不论何时产生输入事件。但是别急，我们首先需要打开输入设备，这是我们的第一个挑战。

正常情况下，设备文件不能被用户读取。这有好的一面，否则每个程序都能够读取所有的键盘事件。这种情况下，键盘记录器太容易实现了。

但是如果KWin以普通用户的方式运行，普通用户又无法读取设备文件，那KWin如何获取输入？为了让KWin获取输入，我们需要特殊的支持。libinput就是为这种情况准备的，它自己不会尝试打开文件，它会使用用户提供的open_restricted函数。KWin就是这么干的，并将打开文件的任务交给了logind。logind允许一个进程控制当前登录会话。并且这个登录会话的控制进程可以打开一些设备文件。所以KWin和logind的dbus API交互，成为登录会话的控制进程，通过logind的API打开设备文件，并将其传递回libinput。

这也是为什么对于整个Wayland会话，KWin在运行时依赖logind的DBus接口。请注意，这并不意味着你需要使用logind或者sysemd。这仅仅意味着需要一个进程来同logind的DBus接口通讯。

KWin中的设备