输入事件成员对鼠标动作的解释 [英] Interpretation of input_event members for mouse actions

问题描述

我正在编写一个基本的基于字符的程序，但是在xterm中运行，并且希望使用鼠标上滚轮上下滚动和左键单击作为键盘上箭头下移和返回的同义词，仅用于额外的用户便利.

我得到了一个select()，所有输入fdset都正常工作，并且异步捕获了原始输入的罚款(无论如何，似乎如此).但是我在从input_event结构中明确解释类型，代码，值成员时遇到了一些麻烦. /usr/include/linux/input.h似乎有一些电动汽车，我正在看到

• EV_REL=0x02(移动鼠标时的相对位置)
• EV_MSC=0x04(其他)，用于所有其他鼠标操作.

问题1:普遍来说是真的吗???我并没有成功地专门搜索与此相关的任何内容.

但是，除了EV，在/usr/include/中我看不到任何代码，值.我的实验显示了以下内容，我进一步询问下面的所有内容是否都是(普遍)正确.甚至更好的是，关于这些内容的(权威性)文档在哪里?我以为使用Google会很容易，但是找不到答案.

任何一个动作似乎都会生成两个或三个单独的input_event，最后一个(第二个或第三个)是类型为= code = value = 0的预告片".我在下面将input_event编写为三元组(类型，代码，值)...

对于左键单击，您将获得三个事件:(4,4,589825)，(1,272,1)，(0,0,0).对于左键单击释放，您将获得:(4,4,589825)，(1,272,0)，(0,0,0).都对吗?到底是589825是什么?

对于向上滚动，您会遇到两个事件:(2,8,1)，(0,0,0).对于向下滚动，您将获得:(2,8，-1)，(0,0,0). (普遍而言)正确吗?

我并不特别在意右键单击或鼠标移动，我只是会忽略它们.因此，我可以对前面的内容进行硬编码(带有一些#define的符号)，还是更像termcap，在某种程度上取决于设备功能?再说一遍，这些东西真实记录在哪里?谢谢.

编辑下面有关NominalAnimal的/dev/input/mice备注

正如NominalAnimal在他的出色回答(再次感谢，Nominal)中所建议的那样，我正在读取/dev/input/event16，这是从查看/proc/bus/input/devices文件中得出的.我想要(并且仍然希望)更通用地进行编码，但是尝试读取/dev/input/mice每次读取仅返回三个字节，而不是包含input_event结构的16个字节.至少那是我做的那件事.而且我想不出任何办法来解码"这些字节以告诉我"event16".

所以我本来应该问这个问题，但是我想我已经讲了足够多了:有什么办法可以从/dev/input/event16中获取所有数据，现在可以从/dev/input/event16中获取所有数据吗?还是有什么办法以编程方式确定哪个/dev/input/event?是用于初始化期间的鼠标(不解析该/proc/文件)?

解决方案

我将假定您正在使用事件输入子系统(而不是/dev/input/mice)，因为您希望直接从特定的鼠标中读取数据，而不是从连接的任何鼠标中读取数据到机器上.

规范文档位于 doc/Documentation/input/event-codes (有关Linux内核的文档中的.txt ).该链接会将您带到最新的网页.

• type=EV_REL, code=REL_WHEEL, value=1(2,8,1)通过向前滚动一个刻度来指示(垂直)滚动轮.如果用户快速旋转滚轮，或者如果它是具有快速"滚轮模式的可编程鼠标，则该值可能大于1.

• type=EV_REL, code=REL_WHEEL, value=-1(2,8，-1)指示(垂直)滚轮后退一个刻度.如果用户快速旋转滚轮，或者如果它是具有快速"滚轮模式的可编程鼠标，则该值可能小于-1.

• 许多鼠标都有水平滚轮.除了代码为REL_HWHEEL.这些功能与垂直滚轮的工作方式相同.

• 其他有趣的type=EV_REL代码是REL_X，REL_Y，REL_Z(相对运动，REL_Z是高度"或3D小鼠离桌子的距离)； REL_RX，REL_RY，REL_RZ用于围绕具有六轴加速度计的3D鼠标之类的东西绕每个轴旋转；和REL_DIAL用于慢跑车轮.

• type=EV_KEY, code=BTN_MOUSE, value=1(1,272,1)表示鼠标单击(在多按钮鼠标上单击鼠标左键)，而value=0(1,272,0)表示释放.

  code也可以是任何其他KEY_或BTN_常量. value释放时为零，按下时为非零.

  尤其是BTN_MOUSE=BTN_LEFT，鼠标右键是BTN_RIGHT，鼠标中键是BTN_MIDDLE，侧面按钮是BTN_SIDE，附加按钮是BTN_EXTRA，任务按钮是BTN_TASK，向前和向后向后按钮(例如在某些Logitech鼠标上)为BTN_FORWARD和BTN_BACK.

• type=EV_MSC, code=MSC_SCAN(值4,4，值)为未由USB/HID标准化的键/按钮事件提供键盘扫描代码.我确实相信您可以忽略这些(由于某些奇怪的原因，它们通常是实际事件的重复，可能是向后Windows兼容性).

• type=EV_SYN, code=SYN_REPORT(0,0)，是一个同步事件；这意味着此时输入事件的状态已经完全更新.

  对于同时"发生的事件，您收到零个或多个输入记录，后跟一个type=EV_SYN, code=SYN_REPORT(0,0).

  通常，HID设备将在一个块中报告所有轴和所有按钮的变化，然后是其中之一.这很有道理，因为我们希望我们的指针根据实际移动而移动，而不仅仅是水平/垂直移动……看起来很奇怪.

总体而言，这是Linux输入子系统，并且非常稳定；它不会改变. (可以添加新的键，按钮等，但现有的键，按钮等永远不要更改.)Linux输入子系统文章 I 和LinuxJournal(从2003年开始)的 II 仍然与背景信息相关.

I'm writing an essentially character-based program, but running in an xterm, and want to use mouse scroll-wheel-up/down and left-clicks as synonyms for keyboard arrow-up/down and return, just for a little extra user convenience.

I've got a select() with all the input fdset's working fine, and am asynchronously capturing the raw input fine (seems so, anyway). But I'm having a little trouble unambiguously interpreting the type,code,value members from the input_event struct. /usr/include/linux/input.h seems to have some EV's, and I'm seeing

• EV_REL=0x02 (relative position when mouse is moved)
• EV_MSC=0x04 (miscellaneous) for all other mouse actions.

Question 1:Is that universally true??? I'm not successfully googling anything much about that specifically.

But beyond EV's, I'm seeing nothing in /usr/include/ for codes,values. My experimenting shows the following, and I'm further asking if everything below is (universally) true. Or even better, where's (definitive) documentation about this stuff? I'd have thought it would be easy to google, but couldn't find answers.

Any one action seems to generate either two or three separate input_event's, with the last (the second or third) a "trailer" with type=code=value=0. I'm writing input_event's below as triples (type,code,value)...

For left-click-press you get three events: (4,4,589825),(1,272,1),(0,0,0). And for left-click-release you get: (4,4,589825),(1,272,0),(0,0,0). Is that all correct? And what the heck's 589825???

For scroll-wheel-up you get two events: (2,8,1),(0,0,0). And for scroll-wheel-down you get: (2,8,-1),(0,0,0). (Universally) correct, again?

I don't particularly care about right-clicks or mouse movements, which I'll just be ignoring. So can I hard-code (with some #define'ed symbols) the preceding stuff, or is it more like termcap, where it's device-capability-dependent in some way? And, again, where's this stuff documented for real? Thanks.

Edit regarding NominalAnimal's /dev/input/mice remarks below

As NominalAnimal suggested in his terrific answer (thanks again, Nominal), I'm reading /dev/input/event16, which I figured from looking at the /proc/bus/input/devices file. I'd wanted (and would still like) to code that more generally, but trying to read /dev/input/mice returns only three bytes per read, rather than the 16 comprising an input_event struct. At least that's what happened to me when I did it. And I couldn't figure any way to "decode" those bytes to tell me "event16".

So I would have asked this originally, but figured I'd talked enough: Is there any way to get all the data from /dev/input/mice that I'm now getting from /dev/input/event16? Or is there any way to programmatically determine which /dev/input/event?? is for the mouse during initialization (without parsing that /proc/ file)?

解决方案

I shall assume you are using the event input subsystem (instead of /dev/input/mice) because you wish to read directly form a specific mouse, not from any mice connected to the machine.

The canonical documentation is at doc/Documentation/input/event-codes.txt in (the documentation for) the Linux kernel. That links takes you to the up-to-date web page.

• type=EV_REL, code=REL_WHEEL, value=1 (2,8,1) indicates (vertical) scroll wheel by one tick forward. The value may be larger than 1 if the user rotates the wheel fast, or if it is a programmable mouse with "fast" scroll wheel mode.

• type=EV_REL, code=REL_WHEEL, value=-1 (2,8,-1) indicates (vertical) scroll wheel by one tick backward. The value may be smaller than -1 if the user rotates the wheel fast, or if it is a progammable mouse with "fast" scroll wheel mode.

• Many mice have horizontal scroll wheels. These work the same way as the vertical scroll wheel, except the code is REL_HWHEEL.

• Other interesting type=EV_REL codes are REL_X, REL_Y, REL_Z (relative movement, REL_Z being "height" or distance from table for 3D mice); REL_RX, REL_RY, REL_RZ for rotation around each axis for things like 3D mice with six-axis accelerometers; and REL_DIAL for jog wheels.

• type=EV_KEY, code=BTN_MOUSE, value=1 (1,272,1) indicates a mouse click (left click on multi-button mice), and value=0 (1,272,0) a release.

  The code can also be any other KEY_ or BTN_ constant. value is zero for release, nonzero for press.

  In particular, BTN_MOUSE=BTN_LEFT, right mouse button is BTN_RIGHT, middle mouse button is BTN_MIDDLE, side button is BTN_SIDE, extra button is BTN_EXTRA, task button is BTN_TASK, and forward and backward buttons (like on some Logitech mice) are BTN_FORWARD and BTN_BACK.

• type=EV_MSC, code=MSC_SCAN (4,4,value) provide keyboard scan codes for key/button events not standardized by USB/HID. I do believe you can just ignore these (they often are duplicates of actual events for some odd reason, probably backwards Windows compatibility).

• type=EV_SYN, code=SYN_REPORT (0,0), is a synchronization event; it means that at this point, the input event state has been completely updated.

  You receive zero or more input records, followed by a type=EV_SYN, code=SYN_REPORT (0,0), for events that happened "at the same time".

  Typically, the HID device will report the changes on all axes and all buttons in one chunk, followed by one of these. This makes a lot of sense, because we want our pointers to move according to the real movement, and not just horizontally/vertically... it'd look weird.

Overall, this is the Linux Input Subsystem, and is extremely stable; it won't change. (New keys, buttons etc. may be added, but existing ones should never change.) The Linux Input Subsystem articles I and II at LinuxJournal (from 2003) are still relevant as background information.

这篇关于输入事件成员对鼠标动作的解释的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！