Linux-hexdump命令调试event驱动

hexdump: 查看文件的内容，比如二进制文件中包含的某些字符串,通常用来调试驱动用

描述

我们以event1为例,当我们insmod挂载了键盘驱动后,出现一个event1设备,

此时没有按键按下，所以event1里面的数据是没有的,那么数据又是从来哪里来？

通过键盘驱动的read函数,若有按键按下,就会上传按键数据给用户层hexdump

因为键盘驱动的input_handler 是:evdev_handler

所以键盘驱动的read函数是: evdev_handler->evdev_fops->evdev_read

进入evdev_read()函数,如下图所示:

evdev_event_to_user()这个函数从字面上来看,显然就是用来上传给用户层的函数,其中buffer是函数参数,指向用户层,所以数据就是event.

我们来看看event的结构体:input_event

把 time里的成员展开如下:

所以我们hexdump调试任何输入子系统event XX驱动时,有信息就会打印上面数据

1.调试键盘驱动

以按开发板的按键 KEY_L,为例(因为数据是从低到高打印的,所以数据是反的):

输入设备（如按键、键盘、触摸屏、鼠标等）是典型的字符设备，其一般的工作机理是底层在按键、触摸等动作发送时产生一个中断（或驱动通过Timer定时查询)，然后CPU通过SPI、I-C或外部存储器总线读取键值、坐标等数据，并将它们放入一个缓冲区，字符设备驱动管理该缓冲区，而驱动的read ()接口让用户可以读取键值、坐标等数据。显然，在这些工作中，只是中断、读键值/坐标值是与设备相关的，而输入事件的缓冲区管理以及字符设备驱动的file operations接口则对输入设备是通用的。基于此，内核设计了输入子系统，由核心层处理公共的工作。drivers/input/keyboardgpio_keys.c基于input架构实现了一个通用的GPIO按键驱动。该驱动是基于platform_driver架构的，名为“gpio-keys”。它将与硬件相关的信息(如使用的GPIO号，按下和抬起时的电平等）屏蔽在板文件platform_device的platform_data中，因此该驱动可应用于各个处理器，具有良好的跨平台性。GPIO按键驱动通过input_event () 、input_sync()这样的函数来汇报按键事件以及同步事件。从底层的GPIO按键驱动可以看出，该驱动中没有任何file_operations的动作，也没有各种IO模型，注册进入系统也用的是input_register_device (）这样的与input相关的API。这是由于与Linux VFS接口的这一部分代码全部都在drivers/input/evdev.c中实现了。

USB 键盘是UDB HID 标准驱动即可支持的。

不过如果你的键盘有背光设置功能，有一些功能键、游戏宏按键。这些东西不被支持。

如果是标准的多媒体控制键，这也是标准的 HID 驱动支持的。

不过前提是你的 Linux 图形界面是用的 evdev 驱动。以前的 keyboard 驱动只支持标准按键。

不过，要是你的 Linux 太老，不支持你主板上 USB 接口，不能用是很正常的。

---