除了 /dev/input/eventx 之外，还有基于更高级别（字符？）的方式来访问 Linux 键盘吗？答案

【问题标题】：is there a higher level (character?) based way to access a Linux keyboard other than /dev/input/eventx?除了 /dev/input/eventx 之外，还有基于更高级别（字符？）的方式来访问 Linux 键盘吗？
【发布时间】：2018-05-12 17:44:46
【问题描述】：

我正在尝试编写一个需要从类键盘 (HID) 设备获取输入的 Linux 守护程序 - 它不是控制台键盘，而是第二个设备（如果有任何区别，它实际上是一维条形码扫描仪） .守护进程将处理它接收到的数据（来自字母数字条形码的“击键”）。

我知道守护进程可以使用 ioctl(EVIOCGRAB) 从 /dev/input/eventx 中获取该设备，然后使用 read() 事件（来自的结构 input_event），这是可行的，但它太低了水平满足我的需要。我不需要知道每个上下键事件，我宁愿不必解码/处理同时键，即我不想知道 KEY_DOWN+KEY_RTSHIFT、KEY_DOWN+KEY_A、KEY_UP+KEY_RTSHIFT、KEY_UP+KEY_A ，我只想收到“A”。

使用输入事件需要编写一大堆额外的代码，只是为了从中得到“A”——当几乎可以肯定存在键盘处理程序（或类似的东西）时，这似乎是浪费时间和精力) 这将比我一起破解代码做得更好 - 我只是找不到它们！

有没有办法将现有的（键盘？）软件层放到 /dev/input/eventx 上，然后守护程序可以从其中独占读取简单的 ascii 流？

对于这个设备，/proc/bus/input/devices 报告...

H: Handlers=sysrq kbd leds event9

...这可能表明某些东西已经在其上放置了一个“kbd”层，但是如何访问它呢？

如果我不使用 EVIOCGRAB，那么当我扫描条形码时，我会看到有关“在 /dev/tty1 上登录失败”的系统日志，因此键盘输入显然是在尝试登录某个终端/shell :-/（有这台机器上也没有 X、桌面等。）

【问题讨论】：

标签： c linux barcode-scanner keyboard-events input-devices

【解决方案1】：

我不知道有这样的库或守护进程。

但是，编写一个守护进程来完成这件事并不像您想象的那么难。在我看来/经验中，如果您不需要实现自动重复（即，仅当类似键盘的设备发送自动重复按键时才执行自动重复），则守护程序非常简单。

特别是，主循环只是一个阻塞读取，然后是零个或多个阻塞写入，中间有一个数组查找。

您可以使用命名管道（在这种情况下，您在打开设备之前打开管道，因为只有在另一个进程打开命名管道或 FIFO 进行读取后，打开才会成功），也可以使用套接字； Unix 域套接字，或者 TCP 或 UDP 套接字（在环回接口上）。我可能会使用命名管道/var/run/barcode-scanner。

我会为输入映射使用单独的配置文件，并且我会支持来自/usr/include/linux/input-event-codes.h 的预处理器宏名称（KEY_），使用辅助 awk 脚本解析为数组。键映射文件可能位于/etc/barcode-scanner/keymap，并包含类似于

的定义

KEY_1 = 1
KEY_NUMERIC_1 = 1
KEY_E = e
shift KEY_E = E
ctrl KEY_E = \5
altgr KEY_E = €
KEY_UP = \033[A

等等。定义文件中未列出的事件将被忽略或选择性地记录。

您可以使用数组，因为最多有 768 个（0 到 KEY_MAX，包括；虽然 0 是 KEY_RESERVED）不同的键盘事件；作为一个二维数组，您可能需要 16 个数组，以支持 Shift、Ctrl、Alt 和AltGr（或右 alt 键），当每个键被按下时。在内部，您只需要处理KEY_LEFTSHIFT、KEY_RIGHTSHIFT、KEY_CAPSLOCK（管理班次状态）； KEY_LEFTALT（管理 alt 状态）； KEY_RIGHTALT（管理 altgr 状态）；和KEY_LEFTCTRL 和KEY_RIGHTCTRL（管理ctrl 状态）。如果您使用位掩码来指示当前状态，则可以将其用作查找数组外部维度的索引。这真的很简单。

请注意，每个数组元素都是一个字符串，当按下该状态的键时发出该字符串（ev.value == 1 表示按键，ev.value == 2 表示自动重复）。除了上述特殊键外，您根本不需要处理密钥释放。

嗯。我想知道是否还有其他人需要这样的守护进程？如果来源在 GitHub，你会使用 GPL3 许可的吗？

【讨论】：

【解决方案2】：

libevdev 库并不完全符合您的要求。但它被广泛使用（例如，由 Xorg 服务器 evdev 和 libinput 驱动程序使用）。

作为主页上的状态：

libevdev 本质上是 /dev/input/eventX 设备的类固醇读取 (2)。

它为您管理ioctl 呼叫、处理事件队列等。

您没有要求的一项附加功能，但它确实很有帮助：它可以同时处理来自多个设备的事件。它允许您监听位于 /dev/input 中的多个设备并在单个线程中处理相同的事件类型。

【讨论】：