做過幾年底層顯示驅(qū)動的開發(fā)調(diào)試我一直覺得這個方向有個特別實在的規(guī)律屏幕亮了不算本事屏幕不亮能定位到具體環(huán)節(jié)才算入門。顯示驅(qū)動調(diào)試工具說到底就是幫你在茫茫多的寄存器、時序參數(shù)、幀緩沖地址、中斷狀態(tài)里快速圈出問題所在的那條“追蹤鏈”。前面幾篇聊了DRM框架、fbdev、panel驅(qū)動這些基礎(chǔ)知識這篇就專門把調(diào)試工具攤開來講清楚——不是羅列工具名單而是告訴你每個工具在哪個環(huán)節(jié)用、怎么讀數(shù)、怎么判斷。這篇內(nèi)容適合正在搞Linux DRM/KMS驅(qū)動、Android顯示HAL或者在做MIPI DSI、eDP、RGB屏調(diào)試的朋友參考。不管你是剛接觸顯示驅(qū)動的初學(xué)者還是已經(jīng)被花屏、閃屏折磨了幾天的老手看完應(yīng)該都能建立一套自己的調(diào)試思路。1. 為什么顯示驅(qū)動調(diào)試極其依賴工具搞顯示驅(qū)動和搞其他內(nèi)核驅(qū)動最大的區(qū)別是大部分情況下你根本看不到代碼在哪一步出錯。網(wǎng)絡(luò)驅(qū)動出問題你還能 ping 一下、看個丟包率存儲驅(qū)動出錯IO 統(tǒng)計直接給你答案。但顯示驅(qū)動一旦出問題現(xiàn)象往往只有幾種黑屏、白屏、花屏、閃屏、偏色。屏幕上顯示的那幾個像素根本不會告訴你“我是因為時序不對才花掉的”。所以做顯示驅(qū)動基本上就是“黑盒調(diào)試”你只能靠外部工具去觀察每一個環(huán)節(jié)到底工作沒有。我習(xí)慣把顯示鏈路拆成四層來看層級對應(yīng)內(nèi)容出問題時的表現(xiàn)主要工具應(yīng)用/合成層SurfaceFlinger、Wayland合成器圖層錯亂、合成性能差dumpsys、glmark2內(nèi)核KMS層DRM驅(qū)動、atomic配置、fb設(shè)置黑屏、分辨率錯誤、模式設(shè)置失敗dmesg、modetest、debugfs面板控制層panel時序、背光、上下電序列白屏、閃爍、背光不亮dmesg、邏輯分析儀物理信號層MIPI/eDP信號質(zhì)量、時鐘頻率花屏、抖動、顯示異常示波器、邏輯分析儀這類分層思路很像網(wǎng)絡(luò)調(diào)試。用過網(wǎng)絡(luò)調(diào)試工具nc的人都知道排查網(wǎng)絡(luò)問題先要搞清楚是鏈路層不通、IP層不通、還是應(yīng)用層的問題顯示驅(qū)動也是一樣的邏輯先定位到層再定位到點最后才去摳具體參數(shù)。換句話說顯示驅(qū)動調(diào)試沒有像nc那樣一個命令通吃全場的“萬能工具”你能做的就是手上備齊一套工具按層去驗證。另一個核心原因是顯示驅(qū)動涉及的時序和狀態(tài)太多了。一個面板的點屏?xí)r序就有幾十個參數(shù)一個atomic commit里面涉及crtc、plane、connector三個對象的狀態(tài)聯(lián)動?？咳庋邸白x代碼找bug”大概率會漏但工具不會騙你——它把真實硬件狀態(tài)擺在你面前比對一下就知道驅(qū)動代碼有沒有按預(yù)期走。2. 內(nèi)核態(tài)調(diào)試工具從日志到運行追蹤這一層是顯示驅(qū)動調(diào)試的主戰(zhàn)場。內(nèi)核態(tài)的工具有個共同特點它們反映的是驅(qū)動程序自身運行時的真實狀態(tài)不是靠猜而是直接讀內(nèi)核的數(shù)據(jù)結(jié)構(gòu)、跟蹤函數(shù)的執(zhí)行軌跡。2.1 drm.debug與dynamic_debug讓內(nèi)核開口說話DRM源碼里到處是DRM_DEBUG、DRM_DEV_DEBUG、DRM_ATOMIC_PRINT這些打印默認情況下這些調(diào)試信息是關(guān)閉的因為全開的話日志刷屏非常嚴重。你需要通過drm.debug參數(shù)來控制輸出級別。drm.debug參數(shù)是按位圖工作的比較常用的位0x01 DRM_UT_CORE核心消息0x02 DRM_UT_DRIVER驅(qū)動通用消息0x04 DRM_UT_KMSKMS相關(guān)0x08 DRM_UT_PRIMEDMA-BUF/PRIME相關(guān)0x10 DRM_UT_ATOMICatomic操作相關(guān)0x20 DRM_UT_VBLANK垂直消隱相關(guān)0x40 DRM_UT_STATE對象狀態(tài)相關(guān)實際操作中像我排查modeset問題會這樣加載modprobe drm drm.debug0x1f0x1f就是0x01到0x10全開正好覆蓋了core、driver、KMS、prime、atomic。這組日志會詳細打印atomic事務(wù)中plane、crtc的更新過程是定位“為什么模式設(shè)置失敗”的第一手資料。如果內(nèi)核模塊已經(jīng)加載了也可以運行時調(diào)echo 0x1f /sys/module/drm/parameters/debug比我更常用的是dynamic_debug機制它可以在不重啟的情況下精確打開某個驅(qū)動的某一類打印echo file drivers/gpu/drm/specific_driver.c line 320 p /sys/kernel/dynamic_debug/control echo module my_display_driver p /sys/kernel/dynamic_debug/control這條命令的意思是打開某個文件的某一行或者整個模塊的動態(tài)打印。排查驅(qū)動初始化流程時把module級別的打印全開再配合dmesg看執(zhí)行順序基本能定位是probe卡死、資源申請失敗還是panel沒就緒?？慈罩疽灿屑记?。dmesg默認輸出很多時候被其他日志擠掉了我會習(xí)慣性地先做一件事dmesg -c清空當(dāng)前日志然后復(fù)現(xiàn)問題這樣后面打印出來的就是本次操作產(chǎn)生的完整日志不會混入系統(tǒng)啟動歷史。復(fù)現(xiàn)問題后再用dmesg回看配合時間戳和調(diào)用順序判斷執(zhí)行路徑。一個小經(jīng)驗是顯示驅(qū)動的初始化日志往往在啟動階段就已經(jīng)刷過去了等到你進系統(tǒng)發(fā)現(xiàn)問題再來看dmesg只能看到交互階段的信息。所以真正排查初始化問題時要在啟動參數(shù)里加上loglevel8并且用串口或內(nèi)核日志抓取工具把啟動過程全程記錄下來。2.2 /sys/kernel/debug/dri文件系統(tǒng)直接讀驅(qū)動內(nèi)部狀態(tài)dmesg是“驅(qū)動主動告訴你發(fā)生了什么”而debugfs下的文件是“你自己去看當(dāng)前驅(qū)動是什么狀態(tài)”。后者在排查問題的時候往往更硬核因為它直接反映內(nèi)核對象在某一時刻的真實取值。先掛載debugfsmount -t debugfs none /sys/kernel/debug然后進到DRM相關(guān)目錄cd /sys/kernel/debug/dri/0 ls里面會有state、framebuffers、connectors、clients等一堆文件。我最?？吹氖莝tate它會把這個DRM設(shè)備下所有對象的狀態(tài)完整打印出來包括crtc的enable/active狀態(tài)、當(dāng)前mode、plane的fb關(guān)聯(lián)、connector的連接狀態(tài)。算是“一鍵查看驅(qū)動全家桶狀態(tài)”。舉個例子排查黑屏?xí)r需要確認crtc到底有沒有被正確使能直接看state文件里的內(nèi)容cat /sys/kernel/debug/dri/0/state輸出里會看到類似這樣的關(guān)鍵信息crtc是enabled還是disabled、active是1還是0、connector是否connected。如果應(yīng)用層和內(nèi)核都認為crtc是enable的但屏幕依然黑屏那問題就不在KMS狀態(tài)配置上而是要去查panel本身的上電時序和信號輸出。這個判斷在調(diào)試中省了我大量時間因為它能直接把“驅(qū)動狀態(tài)沒問題”這一塊排除掉。framebuffers文件也很有用cat /sys/kernel/debug/dri/0/framebuffers它會列出當(dāng)前創(chuàng)建的framebuffer對象包括句柄、寬度、高度、stride行字節(jié)數(shù)、像素格式。很多花屏問題追到最后就是stride計算不匹配。比如用戶空間應(yīng)用按1080寬、每像素4字節(jié)對齊生成了4420字節(jié)的stride驅(qū)動卻按4320字節(jié)去計算掃描地址那從第二行開始就會錯位表現(xiàn)出來就是肉眼可見的花屏條紋。這類問題從debugfs里一眼就能看出來。2.3 ftrace與perf把驅(qū)動運行軌跡錄下來dmesg和debugfs能看到“是什么狀態(tài)”但想看“執(zhí)行了哪些函數(shù)、耗時多少”就得靠ftrace和perf這兩個性能與追蹤大殺器。我排查驅(qū)動長時間才點亮屏幕的問題時最常用的就是ftrace的函數(shù)圖模式echo 0 /sys/kernel/debug/tracing/tracing_on echo function_graph /sys/kernel/debug/tracing/current_tracer echo drm_atomic_commit_tail /sys/kernel/debug/tracing/set_graph_function echo 1 /sys/kernel/debug/tracing/tracing_on cat /sys/kernel/debug/tracing/trace這段操作的意思是打開function_graph追蹤只追蹤drm_atomic_commit_tail這個函數(shù)及其調(diào)用的子函數(shù)然后讀取追蹤結(jié)果。輸出里會看到密密麻麻的函數(shù)調(diào)用縮進能直觀看出內(nèi)核在哪個子函數(shù)里消耗了大量時間。用trace-cmd更省事trace-cmd record -p function_graph -l drm_atomic* trace-cmd reporttrace-cmd會自動管理追蹤緩沖區(qū)的開關(guān)和讀取比手寫echo命令可維護性強得多。我一般會配合一個小腳本把重復(fù)的trace流程自動化思路有點像寫lua腳本去批量執(zhí)行調(diào)試操作——把固定的操作序列固化成腳本然后每次復(fù)現(xiàn)問題時只改目標函數(shù)名節(jié)省下來的時間很可觀。perf在大規(guī)模耗時分析上更強。比如驅(qū)動整體性能下降用perf找熱點函數(shù)是最快的perf top這個命令會實時顯示CPU使用率最高的內(nèi)核函數(shù)。如果看到某個鎖函數(shù)、某個list遍歷函數(shù)占了很高的比例那性能問題大概率就在那里。做顯示驅(qū)動性能調(diào)優(yōu)時我還會用perf record抓一段實際點屏或刷屏的調(diào)用鏈再通過perf report看annotate視圖。很多“屏幕刷新一卡一卡”的問題最后都是通過這個方式定位到驅(qū)動里某個不必要的忙等待循環(huán)。3. 用戶態(tài)測試工具驗證鏈路功能內(nèi)核態(tài)工具解決“驅(qū)動有沒有按預(yù)想工作”的問題用戶態(tài)工具解決的是“整個顯示鏈路能不能跑通、跑得多快”的問題。這是兩條腿缺一條都不行。3.1 modetestKMS功能的照妖鏡modetest是libdrm目錄下的經(jīng)典測試工具凡是做Linux顯示驅(qū)動的人一定都認識它。它用最樸素的方式調(diào)用DRM KMS接口把當(dāng)前的connector、encoder、crtc、plane信息全部枚舉出來這在驗證顯示驅(qū)動最基本功能時極其有用。先看基礎(chǔ)用法# 查看card0下所有connector的狀態(tài) modetest -M card0 -c # 查看所有plane及其支持的像素格式 modetest -M card0 -p # 在connector 32上設(shè)置一個1080x192060Hz的模式 modetest -M card0 -s 32:1080x1920-60-c參數(shù)輸出每個connector的連接狀態(tài)、物理尺寸、支持的mode列表。如果內(nèi)核已經(jīng)成功解析了EDID或者panel驅(qū)動里預(yù)設(shè)了mode這里就能看到mode列表。如果這個列表是空的說明驅(qū)動沒有正確向KMS暴露模式屏幕當(dāng)然點不亮。-p參數(shù)會列出所有plane的尺寸范圍、格式列表和當(dāng)前關(guān)聯(lián)的fb是排查花屏問題的重要入口。最硬核的用法是直接在屏幕上輸出測試彩條modetest -M card0 -s 32:1080x1920 -v這個命令在目標connector上創(chuàng)建一個framebuffer用一段動態(tài)變化的彩條填充并輸出。如果你能看到流暢變化的彩條說明從KMS到panel整條鏈路沒有任何問題剩下的問題就出在應(yīng)用或合成層。如果彩條是花的、錯位的、或者根本沒畫面那就回頭去查內(nèi)核態(tài)。有臺式機環(huán)境跑modetest時有個注意點如果X/Wayland正占著顯卡modetest會拿不到設(shè)備。最簡單的辦法是切到純文本終端下執(zhí)行或者用DRM主設(shè)備權(quán)限直接跑。很多新手說modetest沒輸出排查一番后發(fā)現(xiàn)是權(quán)限問題。用root或者把用戶加入video組可以避免絕大部分權(quán)限坑。3.2 kmscube與glmark2從GPU到屏幕的完整鏈路modetest驗證的是“不經(jīng)過GPU、直接KMS輸出”的鏈路但很多花屏、撕裂問題是GPU渲染和顯示掃描之間的配合出了問題。這時候需要kmscube和glmark2這類工具拉通全鏈路驗證。kmscube在支持EGL/GLE的平臺上跑一個旋轉(zhuǎn)的立方體場景同時會把渲染結(jié)果通過KMS直接提交到顯示層。它既能驗證GPU能不能正常渲染又能驗證渲染結(jié)果能不能正確顯示。我在排查“GPU渲染輸出后屏幕顯示空白”這類現(xiàn)象時第一個跑的就是kmscube。它能幫我快速區(qū)分是GPU沒有渲染出內(nèi)容還是渲染出來了但沒有被正確掃描出。glmark2則是標準OpenGL ES基準測試工具它跑的是大量場景組合測完會給出一個綜合幀率和每項得分。對顯示驅(qū)動調(diào)試來說glmark2的價值在于壓力測試和性能基線如果幀率明顯低于正常水平或者畫面在切換場景時出現(xiàn)撕裂那就是驅(qū)動性能優(yōu)化不到位的信號。配套的還有一個eglinfo工具eglinfo它能輸出EGL版本、擴展列表、surface格式、原生窗口類型等。排查EGL配置時很有用尤其是確認默認surface格式是不是被工作負載意外改了。比如某個app跑完后EGL surface格式從RGBA8888變成RGB565就會導(dǎo)致畫面顏色發(fā)紫或閃一下這個狀態(tài)用eglinfo查一遍馬上就能確認。3.3 邏輯分析儀與示波器物理層最后一道防線內(nèi)核態(tài)和用戶態(tài)工具都查完了問題還是存在那就說明大概率是物理信號層面的問題。這時候必須上硬件工具邏輯分析儀用來抓MIPI DSI、eDP的包命令和時序示波器用來量時鐘頻率、上升沿質(zhì)量和電壓幅值。用邏輯分析儀抓屏過程最核心的是確認一點panel初始化序列到底有沒有按預(yù)期發(fā)出去。我調(diào)試一塊MIPI DSI屏?xí)r屏幕白屏但背光亮內(nèi)核日志顯示panel驅(qū)動probe正常。這時我接上邏輯分析儀抓取MIPI DSI的command lane發(fā)現(xiàn)驅(qū)動根本沒有往panel發(fā)送display on指令因為reset GPIO的時序反了panel一直停留在sleep模式。這個問題從日志上看完全無解只靠邏輯分析儀抓波形才能定位。示波器主要用于測量時鐘頻率和信號質(zhì)量。點屏后如果屏幕閃得很厲害優(yōu)先用示波器量一下pixel clock或MIPI clock的實際頻率。很多時候驅(qū)動里配置的頻率和PLL實際算出來的頻率不一致導(dǎo)致刷新率偏移你以為是驅(qū)動導(dǎo)致閃屏實際上是時鐘參數(shù)算錯了。測量要點是直接在時鐘lane上量頻率然后反推刷新率和modetest里設(shè)置的模式做比對相差在1%以內(nèi)才算正常。4. 實操一次花屏問題的完整排查路徑工具講再多都是紙面功夫真正有價值的是把工具串起來的實戰(zhàn)流程。我拿最近調(diào)試的一塊1080x1920 RGB LCD屏為例完整走一遍排查思路你可以直接參考這個路徑?，F(xiàn)象是內(nèi)核啟動到顯示階段后屏幕有畫面但畫面明顯花屏表現(xiàn)為橫向彩色條紋每隔一段距離就錯位一次。這是顯示驅(qū)動調(diào)試里非常典型的癥狀——數(shù)據(jù)有輸出但幀緩沖被錯誤掃描了。第一步看內(nèi)核日志確認驅(qū)動有沒有報錯dmesg | grep -i drm排查結(jié)果沒有任何error/warning級別的信息驅(qū)動probe成功panel也正常初始化。這說明問題不在于驅(qū)動崩潰或panel沒起來。第二步用modetest確認KMS對象狀態(tài)modetest -M card0 -c modetest -M card0 -p查出connector狀態(tài)正常mode列表里有1080x192060plane也處于正常狀態(tài)。這說明KMS層的模式配置是通的。此時我心里已經(jīng)有一半把握問題出在plane和framebuffer的尺寸/stride匹配上。第三步直接看debugfs確認framebuffer的真實參數(shù)cat /sys/kernel/debug/dri/0/framebuffers重點看stride和pixel_format兩個字段。對比modetest輸出后發(fā)現(xiàn)實際framebuffer的stride是4420字節(jié)而plane配置時計算出來的stride值卻是4320字節(jié)。兩者差了正好100字節(jié)每行。這樣每掃描一行地址就會往后偏移100字節(jié)掃描到屏幕中間就會累積出一大截錯位看起來就是橫向條紋花屏。第四步反向追蹤stride為什么不對。檢查應(yīng)用層的buffer分配邏輯發(fā)現(xiàn)它按1080寬度乘以一個不當(dāng)?shù)腶lignment硬編碼了stride而KMS驅(qū)動的atomic check里沒有校驗stride是否匹配導(dǎo)致錯誤配置一路綠燈直到顯示。修復(fù)方式是在atomic_check中增加stride一致性校驗同時修正應(yīng)用層的分配代碼。這個過程看起來簡單但如果沒有第二步和第三步的工具支撐我大概只能靠反復(fù)改驅(qū)動打印來定位那會慢得多。調(diào)試工具的意義就在于此每一步都能直接排除一類可能逐步縮小范圍到具體對象。我復(fù)盤時總跟新人說花屏問題先還原到“KMS輸出彩條”這一步如果是彩條也花就說明問題在驅(qū)動或物理鏈路如果彩條正常就去看應(yīng)用層buffer。這條分界的價值極高能讓你少走一半彎路。5. 常見問題速查表與排查技巧實錄做多了顯示驅(qū)動調(diào)試發(fā)現(xiàn)很多問題是有規(guī)律可循的。我把這些年積累的問題現(xiàn)象、排查路徑和對應(yīng)工具整理成一張速查表遇到問題直接對照著查現(xiàn)象優(yōu)先排查路徑關(guān)鍵工具黑屏無背光背光控制GPIO/PWM是否配置、背光供電時序dmesg、示波器黑屏有背光panel上下電時序、reset/STB引腳電平、初始化命令邏輯分析儀、dmesg白屏panel是否進入sleep模式、display on是否發(fā)出邏輯分析儀花屏錯位fb的stride/pixel_format/地址對齊debugfs、modetest花屏雪花MIPI lane數(shù)配置、clock頻率邏輯分析儀、示波器閃屏刷新率是否正確、vblank中斷是否穩(wěn)定modetest、ftrace、示波器偏色pixel_format、色域空間、clutmodetest、debugfs撕裂vsync等待缺失、buffer切換不同步glmark2、dmesg觸摸時畫面卡中斷優(yōu)先級、共享鎖競爭perf、ftrace排查時的幾個核心技巧值得單獨寫出來首先復(fù)現(xiàn)問題時一定要保留現(xiàn)場日志。drm.debug全開后再去復(fù)現(xiàn)問題不要復(fù)現(xiàn)完才想起來沒開日志。另外很多顯示問題需要冷啟動才能復(fù)現(xiàn)一定要在開機日志里抓到關(guān)鍵信息否則就白跑一次。其次先用軟件工具排除軟件問題再動硬件工具。每次看到花屏就去接示波器這是最大的誤區(qū)。正確的順序是dmesg看錯誤、modetest看狀態(tài)、debugfs看對象、ftrace看調(diào)用鏈最后才是接邏輯分析儀量波形。很多軟件問題在前三步就能定位。第三改mode之前先備份當(dāng)前配置。尤其帶EDID的屏在調(diào)試時隨意切換一個錯誤模式可能觸發(fā)面板保護。我之前調(diào)試時在連接狀態(tài)下設(shè)置了一個不支持的timing結(jié)果面板直接進入了保護狀態(tài)需要斷電一段時間才能恢復(fù)。第四關(guān)注fb的對齊規(guī)則。DRM驅(qū)動對framebuffer的stride和起始地址一般有對齊要求常見的是64位或者256字節(jié)對齊。用戶空間分配buffer的alignment若不滿足驅(qū)動要求掃描就會出現(xiàn)周期性的錯位。debugfs里看到的stride與實際分配buffer的size對不上基本就是這個原因。第五分清vblank和vsync。vblank是硬件事件vsync是vblank同步到用戶空間后的邏輯?？磀mesg里vblank中斷的頻率如果中斷頻繁丟失或者觸發(fā)異常那就不是應(yīng)用層vsync的問題而是內(nèi)核驅(qū)動對vblank處理有bug。很多幀率上不去的問題追到后來都是vblank中斷被關(guān)掉了。6. 一些調(diào)試環(huán)境方面的細節(jié)補充工具選好了、流程理順了調(diào)試環(huán)境本身也有不少講究。我最早做調(diào)試時吃過不少虧這里多說幾句。建議搞一整套穩(wěn)定的串口日志方案。顯示驅(qū)動和別的驅(qū)動不同屏幕本身就是被調(diào)試對象你沒法在屏幕上打印信息觀察系統(tǒng)狀態(tài)。如果板子沒有串口或者串口沒引出調(diào)試效率會直線下降。所以我做顯示驅(qū)動開發(fā)時第一件事就是把串口拉通而且日志級別開到最高確保無論屏幕亮不亮都能看到內(nèi)核的完整運行過程。另外手邊要有一套穩(wěn)定的測試畫面。我會準備幾個原始色彩畫面純色、漸變、網(wǎng)格用腳本固定輸出到指定分辨率。這些畫面的好處是純色能看出屏有沒有壞點、偏色漸變能看出8bit/10bit色深切換是否正確網(wǎng)格能精確判斷錯位在屏幕的哪個區(qū)域。比隨便放一張照片再觀察“看起來不對勁”要可靠得多。調(diào)試工具的自動化腳本也值得投入時間。顯示驅(qū)動調(diào)試經(jīng)常需要反復(fù)切換分辨率、檢查狀態(tài)、比對日志。把這些操作寫成shell腳本或者用python腳本調(diào)用modetest和debugfs自動比對預(yù)期結(jié)果可以解放大量重復(fù)勞動。就像寫lua調(diào)試腳本一樣把操作序列固化下來出問題跑一遍就能得到結(jié)構(gòu)化結(jié)果比手動一條條敲命令高效得多。最后聊一下工具版本的匹配問題。modetest和debugfs接口在不同內(nèi)核版本上差異不小老內(nèi)核的modetest拿到新內(nèi)核上跑可能解析不了新的DRM對象類型。我用的一直是隨內(nèi)核版本配套的libdrm工具盡量保持工具版本和內(nèi)核版本一致避免因為工具本身解析錯誤產(chǎn)生誤導(dǎo)。畢竟調(diào)試工具自己如果不可靠它給出的結(jié)論也就不可信了?；仡^說一點個人體會。我見過很多人桌上堆滿了高端示波器和邏輯分析儀遇到顯示問題卻還是兩眼一抹黑。工具的多少從來不等于調(diào)試能力強真正的差距在于你有沒有建立一套“分層定位”的思維。先把問題框到某一個層再用這一層對應(yīng)的工具去細化最后才回到代碼層面改東西。這套方法論內(nèi)化之后你會發(fā)現(xiàn)顯示驅(qū)動調(diào)試其實沒有那么多玄學(xué)大部分問題都是“工具用對了答案自己就出來了”。顯示器亮起來的那一瞬間永遠是我做這塊驅(qū)動最爽的時刻。而為了那一次點亮前面無數(shù)次把dmesg翻到底、把modetest輸出對齊、把波形量到小數(shù)點后幾位——這些功夫一點都不會白費。