本合集分享的是，我當初學習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》。

審核編輯 黃宇