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