6、TSP调试方法：使用getevent、使用procfs、使用sysfs、内核日志分析
触摸屏调试，说白了就是跟硬件“对话”。你得知道它报了什么数据，驱动层怎么处理的，中间有没有丢包或者报错。我个人习惯把这四种调试手段当成“四件套”——getevent、procfs、sysfs、内核日志。缺一个，排查问题时就可能抓瞎。
嗯，咱们一个一个来聊。
6.1 getevent：用户态最直接的“听诊器”
getevent 是 Android 系统自带的工具，用来监听输入事件。你想想看，触摸屏本质上就是一个输入设备，它上报的坐标、压力、触摸ID，全都能通过 getevent 抓到。
核心用法：
# 监听所有输入事件
getevent
# 监听特定设备（比如触摸屏）
getevent -t /dev/input/eventX
# 显示原始数据（十六进制）
getevent -l /dev/input/eventX我在项目中遇到过一个问题：用户反馈屏幕偶尔“乱跳”。用 getevent 一抓，发现触摸点 ID 在短时间内频繁变化——原来是驱动里对多指触控的 slot 管理有 bug。getevent 直接暴露了问题，省去了猜疑的时间。
小技巧：用 getevent -l 可以看到事件类型的文字描述，比如 ABS_MT_POSITION_X、SYN_REPORT。新手建议加 -l，不然满屏十六进制容易看晕。
6.2 procfs：驱动暴露的“内脏”
procfs 是内核暴露给用户态的一个文件系统，通常挂载在 /proc 下。触摸屏驱动里，很多调试信息会通过 procfs 输出。
比如，某些触控 IC 的驱动会在 /proc/touchscreen 或 /proc/input 下创建节点，里面放着原始坐标、固件版本、校准参数等。
# 查看触摸屏相关 proc 节点
cat /proc/touchscreen/debug_info
# 或者
cat /proc/input/touchscreen0/status我曾经调试一个低温环境下触摸失灵的案子。用 getevent 看，事件完全没上报。但通过 procfs 读驱动内部状态，发现 IC 的“唤醒标志位”一直是 0——原来是电源管理策略在低温下把触控 IC 休眠了，但没正确唤醒。这个信息，getevent 给不了，只有 procfs 能挖出来。
注意：procfs 节点不是标准化的，每个芯片厂商（Synaptics、Goodix、FocalTech 等）的节点名和内容都不一样。你得先看驱动代码，或者 ls /proc 慢慢找。
6.3 sysfs：控制与配置的“开关面板”
sysfs 挂载在 /sys 下，跟 procfs 不同，它更侧重于设备的控制与配置。触摸屏的校准、灵敏度调节、固件升级，很多都通过 sysfs 暴露。
# 查看触摸屏设备路径
ls /sys/bus/i2c/devices/ # 触摸屏通常是 I2C 设备
# 查看某个属性
cat /sys/bus/i2c/devices/0-0038/ic_ver
# 写入配置（比如切换手势模式）
echo 1 > /sys/bus/i2c/devices/0-0038/gesture_enable说白了，procfs 是“只读的体检报告”，sysfs 是“可调节的控制面板”。调试时，我经常先读 procfs 看状态，再通过 sysfs 改参数，最后用 getevent 验证效果。
| 调试手段 | 主要用途 | 数据流向 |
|---|---|---|
| getevent | 监听用户态输入事件 | 内核 → 用户态 |
| procfs | 读取驱动内部状态 | 内核 → 用户态（只读为主） |
| sysfs | 配置驱动参数 | 用户态 → 内核（可读写） |
| 内核日志 | 查看驱动运行时的打印信息 | 内核 → logcat/dmesg |
6.4 内核日志分析：驱动层的“黑匣子”
内核日志，就是驱动开发者的“日记本”。驱动里每执行一个关键步骤，比如初始化、中断处理、上报坐标，都可以通过 printk 或 dev_dbg 打印出来。
# 抓取内核日志
dmesg | grep -i touch
# 实时查看（推荐）
adb shell logcat -b kernel | grep -i touch
# 或者直接看 /proc/kmsg（需要 root）
cat /proc/kmsg | grep touch我记得有一次，客户反馈屏幕边缘触摸不灵敏。用 getevent 看，边缘区域确实没上报。但为什么没上报？打开内核日志，发现驱动里有一个“边缘抑制”功能——为了防误触，驱动在边缘区域直接丢弃了事件。日志里打印了 touch: discard event at edge。嗯，找到根因了，改一下阈值就行。
建议：调试阶段，让驱动工程师把 dev_dbg 级别的日志打开。虽然会影响一点性能，但排查问题快得多。量产版本再关掉。
6.5 四种手段的配合使用
实际调试中，很少只用一种手段。我一般按这个顺序来：
- 先看内核日志：有没有报错？初始化成功了吗？中断有没有触发？
- 再用 getevent：确认用户态是否收到事件，坐标对不对。
- 读 procfs：如果 getevent 没数据，看看驱动内部状态是否正常。
- 调 sysfs：尝试修改参数，看能不能恢复。
下面这张图，是我自己总结的调试流程，你可以参考一下：
举个例子：你发现触摸没反应。先 dmesg | grep touch，看到 i2c transfer failed——哦，硬件通信有问题。然后读 procfs 确认 IC 状态，发现寄存器读回来全是 0xFF。再用 sysfs 复位一下，还是不行。最后定位到是 I2C 总线上的上拉电阻虚焊了。你看，四件套走一遍，问题基本藏不住。
总结一句话：getevent 看表象，procfs 看内里，sysfs 动手调，内核日志看全程。四个工具配合好，触摸屏调试没烦恼。
公众号:蓝海资料掘金营，微信deep3321