驱动之路#12：如何调试Input设备？

本合集分享的是，我当初学习Linux驱动的来时路——《《驱动之路》开篇：自序&前言》。

正文

经过前面 Input 子系统系列文章，我们已经很清楚 Input 子系统的数据上报流程（如下图），这正是我们调试 Input 设备时的技术自信。Input设备的工作链路很简单： 硬件→ 驱动→ Linux Input子系统 → 应用层，调试的核心就是“从下到上”验证每一环是否正常，哪环断了就针对性解决。

下面跟大家分享我的 Input 设备调试思路，仅供参考～

调试流程

当我们配置完软件并连接 Input 设备后，接下来就进入调试流程。

第 1 步：确认设备是否被系统识别

先通过 cat /proc/bus/input/devices判断Input设备有没有被驱动识别，这是最基础的一步。

小提示：关键看输出中的「Name」和「Handlers」，比如触摸屏会显示“goodix-ts”，Handlers对应“event6”（设备节点）； 若没找到目标设备，优先排查：驱动是否加载、硬件接线是否松动（如I2C触摸屏的SDA/SCL引脚）、设备树配置是否正确（如I2C地址、中断引脚）。

第 2 步：验证原始事件是否正常

如果设备已识别，但操作没反应，可以使用getevent/hexdump/od （Linux 与 Android 支持不同命令）等命令监听原始事件，判断驱动是否能正常上报数据。

 比如，执行命令 hexdump /dev/input/event6 ，然后操作Input设备（如触摸屏幕、按按键），观察输出；

正常情况：会持续输出事件，比如触摸屏会有ABS_MT_POSITION_X（X坐标）、ABS_MT_POSITION_Y（Y坐标）事件。

异常情况：无输出→驱动未正确上报事件，检查驱动probe函数是否执行、中断是否触发（关键点）。

第 3 步：用evtest/tslib 做更细致的功能验证

getevent/hexdump/od 等命令看原始数据，evtest/tslib(触摸专用) 能更直观地看到事件细节，适合验证功能是否达标。

排查思路

无论是硬件还是软件都特别要留意中断信号，中断是 Input 设备数据上报的关键！比如调试触摸屏时，只要触摸芯片正常工作，触摸屏幕，中断引脚的电平就应该产生变化，驱动程序通过捕获其电平的变化触发中断函数，从而实现数据上报。

说句废话：具体问题具体分析。不过实际情况确实如此，这里无法列出所有情况，只能提供一些常见问题的排查思路。

设备未识别

（1）驱动未加载：看dmesg日志（dmesg | grep input）是否有报错，根据报错 log 进行排查；

（2）dts 配置错误：检查设备树中Input设备的节点配置（如I2C地址、中断引脚、compatible属性），确保与驱动匹配。

有设备节点但无事件输出

（1）中断未触发：用 cat /proc/interrupts 查看中断是否有计数，无计数→硬件接线错误或中断配置错误；

（2）驱动未初始化：查看dmesg日志，看驱动probe函数是否有报错（如资源申请失败）。

（完）

本人专注 Linux 驱动 & Linux/Android BSP 开发调试，可接外包项目/技术支持/问题定位。有需求或交个朋友可加微信：【Chen_WeChat2026】。

更多原创技术文章：《README 2026》。

审核编辑 黄宇