顯示器驅動這類東西平時不太會被普通用戶注意到但負責嵌入式設備、瘦客戶機或老式商用主板的人大概率見過 SM750 這個芯片。它是一顆很常見的 2D 顯示控制芯片經(jīng)常出現(xiàn)在國產(chǎn)工控主板、云終端、醫(yī)院掛號機、銀行排隊機這類設備里。這類設備的通病是Windows 下驅動好找Linux 下就比較尷尬以前要么靠內核里已經(jīng)很邊緣的 framebuffer 路徑要么找第三方閉源包湊合。這次 SM750 的 HDMI DRM 驅動發(fā)布支持 2048 寬輸出和 2560x1080 超寬屏分辨率對還在維護這類設備的人來說是一個值得跟進的改變。這篇文章不打算只復述發(fā)布信息。我會把 SM750 的顯示鏈路、DRM 驅動的作用、2560x1080 這類超寬分辨率是怎么被支持的、以及拿到驅動后怎么驗證、出問題怎么排查一次講清楚。如果你正在做嵌入式 Linux 開發(fā)、顯示驅動移植或者手頭正好有一臺帶 SM750 的設備需要接 2K 級別顯示器下面這些內容可以給你省點時間。1. SM750 這個芯片和 DRM 驅動到底解決了誰的痛點1.1 先搞清楚 SM750 是哪類芯片SM750 不是 CPU也不是主力顯卡它是一顆負責顯示輸出的控制芯片。在很多商業(yè)整機里主板上的處理器可能很弱板載一顆顯示芯片專門承擔像素輸出和簡單的 2D 加速把主 CPU 從顯示任務里解放出來。SM750 就是這類角色。它的典型特征有三個2D 能力為主能處理 framebuffer、窗口疊加、基本 2D 加速但 3D 能力很弱。顯存獨立但不大常見板載版本配的是獨立顯存容量通常在幾十 MB 這個量級不像桌面顯卡那樣有幾個 GB。接口多樣具體板卡上可能是 VGA、DVI、LVDS、HDMI 或其中幾種組合。標題里提到的 HDMI 輸出要看板上實際引出的接口和物理層方案。這類芯片之所以在國內設備里出現(xiàn)頻率高是因為它足夠便宜穩(wěn)定性也經(jīng)過了相當長時間的市場驗證。對商用設備來說顯示不追求炫追求的是穩(wěn)定、低成本、能長時間開機不花屏。1.2 以前 Linux 下驅動為什么讓人頭疼如果只是跑 WindowsSM750 的驅動基本不用操心廠商會提供安裝包。但 Linux 環(huán)境就復雜了。老一代的方案是走內核的 sm750fb framebuffer 驅動配合 Xorg 里的老模塊使用。這套東西在 2020 年之前的發(fā)行版里還能湊合但這些年 Linux 顯示棧已經(jīng)明顯轉向 DRM/KMS 體系。KMS 的意思是 Kernel Mode Setting由內核統(tǒng)一管理顯示模式、顯存、連接器狀態(tài)。fbdev 老路徑在新內核里越來越邊緣化。這帶來的實際問題是新內核的某些特性兼容不上或者需要額外補丁。桌面環(huán)境、Qt 應用、Wayland 合成器對新驅動的適配越來越依賴 KMS 接口。出問題時日志不直觀很難判斷到底是芯片沒啟動、模式?jīng)]設對還是上層合成器沒收到信號。這次發(fā)布的 SM750 HDMI DRM 驅動本質上就是給這顆芯片補上了通往現(xiàn)代 Linux 顯示棧的接口。1.3 誰最需要關注這個發(fā)布我認為主力受益者有三類維護存量設備的人手里有大量 SM750 工控板在跑 Linux需要在新內核上繼續(xù)穩(wěn)定輸出。做嵌入式 Linux 產(chǎn)品的人正在選型顯示方案希望芯片能被內核主線 DRM 框架接管而不是依賴廠商私有補丁。學習 Linux 驅動開發(fā)的人SM750 的驅動結構不算臃腫作為 KMS 驅動學習樣本很合適能看清 connector、encoder、crtc 之間的關系。如果你只是臺式機用戶手頭也沒有 SM750 設備那這篇內容可以當作顯示棧知識看不需要真的去刷驅動。2. 2048 寬輸出和 2560x1080 超寬屏背后靠的是顯示時序能力2.1 分辨率的本質不是“加一行設置”很多人以為支持某個分辨率就是把分辨率數(shù)值寫進某個列表然后重啟。實際上顯示分辨率背后是一整套時序參數(shù)通常用一個叫 modeline 的東西表示。它包含有效圖像的寬度和高度比如 2560x1080。像素時鐘頻率也就是每秒要輸出多少個像素點。水平前肩、水平同步、水平后肩。垂直前肩、垂直同步、垂直后肩。刷新率。顯示器不會自己產(chǎn)生一張完整的畫面它會按固定的節(jié)奏刷新。顯卡或顯示控制芯片負責在正確的時刻把像素數(shù)據(jù)送到接口上。這個節(jié)奏如果和顯示器對不上要么黑屏要么畫面閃爍撕裂要么直接無法點亮。所以DRM 驅動支持 2560x1080不只是把分辨率數(shù)值暴露出來而是要保證芯片的顯示控制器能夠生成符合這個分辨率的時序并且把足夠大的 framebuffer 分配好。2.2 2048 寬這條線有什么講究這次發(fā)布里提到“2048 寬輸出”這個數(shù)字很關鍵。很多老一代顯示控制芯片有一個隱形的寬度邊界超過一定寬度之后內部 FIFO 帶寬、行緩沖對齊、內存訪問策略就會出問題。2048 這個數(shù)值在顯示領域經(jīng)常作為一個分界點出現(xiàn)因為它是 2 的冪對齊友好。支持 2048 寬輸出意味著顯示控制器在寬度大于 1920 的范圍內能穩(wěn)定分配行緩存。超過 2048 的桌面尺寸不再必須走裁剪或縮放路徑。驅動會為寬屏模式準備合適的 framebuffer 對齊策略。這不是一個單純“把上限調大”的操作它涉及內存帶寬的驗證和模式表的擴展。2.3 2560x1080 是超寬屏里的特殊檔位2560x1080 是 21:9 超寬屏像素量大約是 1920x1080 的 1.33 倍。它在帶寬需求上已經(jīng)接近 2K 級別對顯示控制芯片的像素時鐘要求比 1080p 高出一截。如果芯片的 PLL 或時鐘源不能輸出足夠高的像素時鐘單靠軟件改 modeline 是點不亮的。所以這次驅動能支持 2560x1080背后至少意味著三件事驅動里的模式生成邏輯已經(jīng)能構造出 2560x1080 的時序參數(shù)。芯片的時鐘能力足夠覆蓋這個分辨率所需的像素時鐘。framebuffer 的尺寸計算、行偏移和內存對齊邏輯已經(jīng)能處理 2560 寬度的場景。不過要注意一點驅動支持這個模式不代表任何一塊 SM750 板子都能穩(wěn)定輸出。具體能不能點亮還取決于板載輸出接口、轉接芯片、線材和顯示器本身。尤其是 HDMI 接口如果板卡是從 DVI 物理層轉接出來的那么信號在帶寬和 EDID 傳達上會有限制。這個坑后面單獨說。2.4 模式列表從哪來EDID 和內置模式表DRM 驅動獲取可用分辨率的方式主要有兩種從顯示器讀取 EDID顯示器通過 DDC 通道把支持的模式列表發(fā)給驅動這是最常見的路徑。驅動內置模式表當 EDID 缺失、損壞或顯示器不帶 EDID 時驅動根據(jù)硬件能力提供一個固定模式列表。這次發(fā)布里強調支持 2560x1080更多是指驅動層面具備生成這個模式的能力。實際插上顯示器后是否自動出現(xiàn)在模式列表里要看你插的顯示器 EDID 是否完整地支持這個分辨率。如果顯示器 EDID 正常通常不需要手動干預。如果 EDID 缺失你就得靠驅動內置模式表或者手動添加 modeline。這個操作后面會提到。3. 從 DRM 內核到 Qt 應用顯示鏈路里的每一次中轉3.1 完整鏈路是什么在 Linux 桌面環(huán)境下一個 Qt 窗口最終顯示在屏幕上要經(jīng)過很多層。SM750 的 DRM 驅動處于最底層但如果你要調試為什么畫面不對光看驅動不夠。完整的鏈路是這樣的屏幕硬件 ← DRM 內核驅動 ← X server(Xorg) ← X11 協(xié)議 ← Qt(xcb 插件) ← 你的 Qt 程序如果用的是 Wayland鏈路則是屏幕硬件 ← DRM 內核驅動 ← Weston/Sway 等合成器 ← Wayland 協(xié)議 ← Qt(wayland 插件) ← 你的 Qt 程序每一層都在上一層的輸出上做處理。DRM 驅動負責把最底層的模式設置好Xorg 選一個分辨率、組織 framebufferX11 協(xié)議負責窗口、繪制和事件分發(fā)Qt 通過 xcb 插件和 X server 通信。只要顯示模式不匹配任何一層都可能出現(xiàn)問題。3.2 DRM/KMS 到底在鏈路里扮演什么角色DRM 驅動在 Linux 顯示體系里是內核和用戶的邊界。它提供幾個核心對象CRTC掃描輸出控制器決定從 framebuffer 里怎么讀出數(shù)據(jù)并產(chǎn)生時序信號。Encoder把像素信號編碼成特定接口協(xié)議比如 HDMI、DVI、LVDS。Connector物理連接器檢測是否有顯示器接入維護 EDID 和當前模式狀態(tài)。Plane顯示平面負責把 framebuffer 內容合成到輸出上。KMS 的價值在于上面這些對象全部由內核統(tǒng)一管理。用戶空間的 Xorg、Wayland 合成器不用直接去操作寄存器而是通過 DRM 提供的接口來設置 mode、提交 framebuffer。這帶來的好處是只要 SM750 驅動把 KMS 接口實現(xiàn)好上層的 Xorg、Qt、GTK 都無需專門適配這顆芯片。這也是為什么現(xiàn)在很多人強調 KMS而不是繼續(xù)維護老 fbdev。3.3 用戶空間怎么操作 DRM 設備驅動加載成功后系統(tǒng)會產(chǎn)生 /dev/dri/card0 之類的設備節(jié)點。用戶空間的工具和庫通過這個節(jié)點訪問顯示能力libdrm 是底層庫提供 ioctl 封裝。modetest 可以查看連接器狀態(tài)、模式列表和 framebuffer 信息。xrandr 是 Xorg 環(huán)境下的分辨率管理工具。weston 或 sway 這類合成器直接走 DRM/KMS。這意味著即使你沒有圖形界面也可以先用命令行工具驗證 SM750 驅動是否正常工作。圖形界面出問題時先用 modetest 排除內核驅動下面的問題再往上檢查 Xorg 或合成器效率要高得多。3.4 為什么鏈路長出問題時要分層看待很多人在顯示出問題時第一反應是“驅動壞了”。但實際上顯示鏈路每一層都有可能出現(xiàn)兼容性問題驅動層模式設置失敗、連接器檢測不到、顯存分配失敗。Xorg 層配置錯誤、驅動加載順序不對、分辨率列表沒刷新。應用層Qt 的 xcb 插件沒有拿到正確的屏幕縮放窗口畫不出來。所以排查時要先確認 DRM 層正常再用 xrandr 確認 Xorg 層最后再去看 Qt 或者具體應用。不要一上來就懷疑驅動也不要一黑屏就去改源碼。4. 拿到驅動后怎么驗證 2560x1080 能不能開出來4.1 建議先做一輪最小驗證如果你手里有一套帶 SM750 的設備想驗證這次發(fā)布的能力我建議不要直接接上超寬屏就開搞。先把環(huán)境固定下來做一輪最小驗證。需要準備的東西帶 SM750 的主板或整機。一根可靠的 HDMI 或 DVI 線根據(jù)板卡的實際接口來。一臺支持 2560x1080 的顯示器最好確認顯示器本身的 EDID 信息是完整的。Linux 系統(tǒng)內核版本要足夠新才能包含或加載這個 DRM 驅動。modetest、dmesg 這些基本維護工具。如果內核里還沒有集成這個驅動需要先按模組或補丁方式把它裝進去。加載方式取決于驅動是編譯進內核還是作為外部模塊不同環(huán)境不一樣。建議先看驅動發(fā)布說明里給的加載路徑。4.2 第一步確認驅動是否加載成功開機之后先看內核日志里有沒有對應的驅動信息dmesg | grep -i sm750如果驅動正常加載應該能看到設備識別、連接器掃描或者模式列表初始化的日志。如果沒有輸出先確認驅動模塊是否被加載lsmod | grep sm750再檢查設備節(jié)點是否創(chuàng)建ls -l /dev/dri/正常情況下會有 card0 或者 card1。如果設備節(jié)點不存在多半是驅動沒有編譯進去或者設備樹、PCI 枚舉階段沒有識別到硬件。4.3 第二步用 modetest 查看模式列表modetest 是 DRM 調試中最直接的工具。先列出所有設備modetest -M sm750或者先不管驅動名直接掃描modetest -p重點看連接器部分的輸出。正常情況下會列出連接器狀態(tài)、物理接口類型和所有可用模式。如果連接器狀態(tài)是 connected并且模式列表里有 2560x1080 或 2560x108060Hz說明驅動已經(jīng)把這個模式暴露出來了。如果連接器狀態(tài)是 disconnected先檢查線材、接口和顯示器電源。4.4 第三步在 Xorg 下切換分辨率如果你的系統(tǒng)跑的是 Xorg可以先用 xrandr 確認當前輸出xrandr輸出里會列出顯示器名稱和可用分辨率列表。如果 2560x1080 在列表里直接切換xrandr --output HDMI-1 --mode 2560x1080注意輸出名稱不一定是 HDMI-1要以 xrandr 實際顯示為準。切換之后觀察畫面是否正常鋪滿有沒有黑邊、花屏或閃爍。如果 xrandr 列表里沒有 2560x1080但顯示器確實支持可能是 EDID 沒有把這個模式傳回來?？梢試L試手動添加 modeline。具體做法是先用 cvt 生成時序參數(shù)再用 xrandr --newmode 和 --addmode 注入比如cvt 2560 1080 60 xrandr --newmode 2560x1080_60.00 實際時序參數(shù) xrandr --addmode HDMI-1 2560x1080_60.00 xrandr --output HDMI-1 --mode 2560x1080_60.00這種方式在驅動層已經(jīng)支持、只是 EDID 未上報時比較有用。如果驅動層本身沒有這個模式能力手動注入也不一定能點亮。4.5 第四步用 Qt 或通用圖形程序驗證分辨率切換成功后還需要確認上層應用能正常適配。Qt 程序在 X11 下走 xcb 插件它會讀取 X server 提供的屏幕尺寸。如果 Xorg 已經(jīng)在 2560x1080 下工作Qt 應用一般會自動填滿屏幕。你可以在普通程序里放一個全屏窗口或者在終端里查看顯示服務器報告的屏幕尺寸xdpyinfo | grep dimensions如果 dimensions 顯示的是 2560x1080說明鏈路已經(jīng)通到 X11 層。Qt 程序的窗口布局、鼠標坐標、縮放比例都以這個尺寸為準。如果里面某個 Qt 應用在超寬屏下布局錯亂不要先怪 SM750 驅動。先確認 X11 層尺寸是否正確再用 QT_SCALE_FACTOR 或 Qt 的屏幕縮放機制去調應用。問題大概率出在應用對寬屏適配而不是顯示驅動。4.6 驗證結果怎么判斷可以按下面的表來判斷每一層是否正常驗證層命令或位置正常結果異常表現(xiàn)驅動加載dmesg能看到 SM750 設備識別無日志設備節(jié)點缺失DRM 設備/dev/dri/card0存在且可讀設備不存在連接器狀態(tài)modetest -pconnected有模式列表disconnected模式列表為空模式設置xrandr2560x1080 可用并可切換模式缺失切換后黑屏X11 尺寸xdpyinfodimensions 為 2560x1080尺寸仍為舊分辨率Qt 應用窗口顯示全屏鋪滿文字不糊布局錯亂窗口越界這一套走完基本能確定 SM750 DRM 驅動在你手頭這塊板子上是否正常工作。5. 黑屏、分辨率缺失、輸出空白按這個順序排查5.1 容易誤判的幾個點SM750 這類嵌入式顯示芯片的調試同樣一個黑屏現(xiàn)象原因可能差得很遠。我建議不要上來就改驅動源碼先按下面的順序過一遍很多時候問題根本不在驅動本身。常見的誤判有這些“驅動沒加載”實際上是內核沒有把硬件枚舉出來?！膀寗硬恢С?2K”實際上是 EDID 沒讀到顯示器模式?jīng)]上報?！癏DMI 壞了”實際上線材或轉接頭的 DDC 通道有問題導致 EDID 傳輸失敗?！癚t 顯示不了”實際上是 Xorg 層的分辨率沒有切換成功。排查的第一步永遠是把現(xiàn)象寫清楚是完全沒有信號還是畫面閃、花屏還是只有部分分辨率不可用。5.2 排查順序先物理再 EDID再內核再上層我從實際經(jīng)驗里總結的排查鏈路是這樣的物理接口確認板卡輸出接口和顯示器輸入接口一致。SM750 板卡如果是 DVI 轉 HDMI 座要理解它的信號本質是 DVI帶寬上限和 EDID 特點會和原生 HDMI 不同。線材和供電換一根短一點的線排除線材損耗。HDMI 線的質量對高分辨率影響很明顯尤其是 2560x1080 這種接近 2K 帶寬的場景。EDID用 modetest 看連接器是否 connected看模式列表里有沒有 2560x1080。如果沒有多半是 EDID 沒讀到或顯示器的 EDID 不完整。內核日志dmesg 里看有沒有和 SM750、DRM、HDMI 相關的錯誤。驅動參數(shù)有些板卡需要額外指定輸出類型或初始化方式看發(fā)布說明里有沒有相關參數(shù)。上層顯示服務器確認 X org 或合成器有沒有接住驅動提供的模式xrandr 能不能切到目標分辨率。應用層適配最后才考慮 Qt、GTK 或者其他應用對超寬屏的適配問題。下面是常見問題和排查方向現(xiàn)象優(yōu)先排查方向次要排查方向完全無信號線材、接口、顯示器輸入源驅動是否加載連接器狀態(tài)連接器 disconnectedEDID 通道、線材、物理接口驅動對連接器檢測是否正常模式列表為空EDID 缺失顯示器是否上電驅動內置模式表是否啟用有模式但切換黑屏像素時鐘是否足夠時序是否匹配線材帶寬刷新率是否過高切換后不斷閃爍線材質量、刷新率、HDMI 時鐘穩(wěn)定性顯示器內部縮放是否觸發(fā)分辨率超過 2048 后花屏行緩存、framebuffer 對齊驅動是否有寬度限制遺漏重啟后分辨率丟失Xorg 配置沒有保存顯示器 EDID 在上電時序上不穩(wěn)定5.3 關于“EDID 沒讀到”這件事EDID 是顯示器和驅動之間溝通的“身份信息”它是一段 128 字節(jié)或更長的數(shù)據(jù)存放在顯示器內部的存儲芯片里通過 DDC 通道傳輸。DDC 通道依賴物理引腳的連通性HDMI 線里如果有一根針接觸不良、轉接頭質量問題都可能導致驅動讀不到 EDID進而拿不到 2560x1080 模式。讀不到 EDID 時modetest 里連接器狀態(tài)通常會變成 disconnected或者模式列表為空。這時可以先強制指定一個 EDID 或 modeline 來驗證硬件本身能不能輸出。不過要注意強制的 modeline 如果和顯示器內部時序不能對上畫面可能依然無信號。更穩(wěn)妥的做法是換線。換顯示器。檢查轉接頭是否支持高帶寬。如果這些都不行再考慮驅動層面強制注入模式。不要一開始就懷疑 SM750 驅動對超寬屏支持有問題。5.4 關于轉接和物理層差異的提醒SM750 這顆芯片歷史悠久不同板卡對 HDMI 的實現(xiàn)方式不一樣。有的板子引出的是原生 HDMI 信號有的則是 DVI 信號通過轉接芯片變成 HDMI 座。兩種方案對調試的影響不太一樣原生 HDMI 支持音頻和完整 EDID 通道更接近普通顯示器場景。DVI 轉 HDMI 通常不支持 HDMI 音頻EDID 也可能只暴露 DVI 模式這時 2560x1080 這種依賴高帶寬的模式可能不會自動出現(xiàn)。判斷方法很簡單看板卡資料里 HDMI 是否支持音頻傳輸。如果資料沒寫清楚可以用 edid-decode 工具讀取 EDID 內容看里面的接口類型標識。注意如果板卡是 DVI 物理層遇到 2560x1080 點不亮不要急著罵驅動。先確認物理層方案是否支持這個帶寬。另外熱詞里提到的“edp 轉 hdmi out 時 panel 時序、lane 和速率等參數(shù)要求”對 SM750 場景也有參考意義。顯示接口轉換時最終輸出的時序要以目標接口的帶寬和時鐘為準不是輸入源多少分辨率輸出就一定能按多少分辨率跑。中間多一個轉接芯片就多一個帶寬瓶頸和時序校準環(huán)節(jié)。5.5 什么時候才需要去動驅動或設備樹如果你已經(jīng)確認物理接口、線材、顯示器都沒問題EDID 也能正常讀取但模式列表里就是沒有 2560x1080這時才考慮驅動或設備樹層面的處理。驅動層面常見做法是在驅動內置 mode table 中追加上目標 modeline。檢查 framebuffer 最大寬度限制必要時修改寬度判斷邏輯。確保像素時鐘計算支持目標頻率。設備樹層面常見做法是檢查輸出接口類型是否與硬件對應。確認連接器默認狀態(tài)避免熱插拔檢測異常。如果板卡有多個顯示輸出確認路由是否正確。這些操作需要對 DRM 框架和具體板卡硬件都比較熟悉新手建議先拿 modetest 和 xrandr 把問題定位到具體層次再決定要不要改內核層。不要一上來就找驅動源碼改那樣容易把簡單問題復雜化。6. 開源驅動不只是一份源碼更是一條可以長期維護的路徑6.1 閉源驅動的老問題還在在 SM750 這類芯片上廠商通常會提供 Windows 驅動Linux 支持則不一定完整。有些廠商會提供預編譯的二進制模塊但二進制模塊有幾個長期痛點內核版本升級后模塊可能加載失敗或需要重新編譯適配。出現(xiàn)問題時沒有源碼可查只能靠日志猜。用戶空間和內核接口變化時廠商更新速度不一定跟得上。無法深度定制比如加一個自定義分辨率、改某種時序輸出。對消費級用戶來說閉源驅動勉強夠用。但對嵌入式產(chǎn)品和個人開發(fā)者來說閉源驅動意味著一種不可控你依賴廠商的更新節(jié)奏依賴它愿意支持的內核版本依賴它在安全補丁上的態(tài)度。6.2 開源 DRM 驅動帶來的改變這次 SM750 的 DRM 驅動以開源方式發(fā)布最大價值不是“免費”而是把顯示控制能力納入到 Linux 內核的公開框架里。具體能帶來這些實際好處可讀源碼出現(xiàn)問題時可以打開源碼看寄存器操作、模式設置和連接器檢測邏輯?？杉尤罩究梢杂?printk、dev_dbg 等手段在關鍵路徑上打印信息幫助定位?？筛膮?shù)如果你想增加分辨率、調整時序、適配特殊面板可以在源碼層面修改并重新編譯?？筛骶€如果驅動進入內核主線后續(xù)內核升級會有更持續(xù)的維護?？蓞⒖紝W習DRM 驅動開發(fā)門檻不低一套簡潔的 2D 驅動實現(xiàn)可以讓學習者更快理解 KMS 對象關系。6.3 開源不代表零維護這里要說一句不那么樂觀的話開源驅動發(fā)布不等于裝上之后就一勞永逸。DRM 內核 API 也會演進驅動需要跟著調整。如果你的產(chǎn)品要長期維護不能只下載一次源碼就丟在那里要關注內核版本變化對驅動的影響。另外開源驅動只是把能力開放出來具體到某個板卡上的初始化時序、供電要求、接口物理層可能還需要板卡廠商提供補充信息。開源解決了“有路可走”的問題但不等于每個硬件細節(jié)都自動對齊。所以我的建議是把驅動源碼納入到你的鏡像構建體系里方便重復構建和保存補丁。記錄板卡型號、內核版本、顯示接口、面板參數(shù)。每次換內核大版本時先跑一輪單分辨率和多分辨率切換驗證。對于從產(chǎn)品選型角度考慮的人開源驅動還意味著供應鏈上的選擇更自由。你不一定非要用某家廠商封裝的私有顯示方案可以按 DRM 框架選擇適合自己的顯示控制芯片。6.4 對 Linux 驅動學習者的意義如果你正在學 DRM 驅動開發(fā)SM750 的驅動是一個不錯的入門觀察對象。它不像那些復雜的 GPU 驅動那樣有海量調度、顯存管理、固件加載邏輯但它把 KMS 的骨架體現(xiàn)得比較清楚。你可以重點看這些部分驅動如何注冊 DRM 設備。連接器的檢測函數(shù)怎么寫。CRTC 的 mode_set 如何處理分辨率變化。像素時鐘和 mode 參數(shù)的計算路徑?？炊@些小而完整的實現(xiàn)再回頭去讀更復雜的驅動比如各種 SoC 內置顯示控制器或獨立顯卡驅動會輕松不少。7. 什么情況下用得上什么情況下別指望太多7.1 很適合用的場景你可以在這些場景里放心考慮 SM750 DRM 驅動的支持Linux 桌面的商業(yè)終端云終端、前臺展示機、信息查詢機。這些設備不追求 3D 性能只要穩(wěn)定輸出文字和視頻即可。嵌入式 Linux 產(chǎn)品需要長期固定顯示界面希望顯示輸出由內核統(tǒng)一管理。超寬屏商務展示需要輸出 21:9 內容的設備比如接待臺、大屏信息終端。驅動學習和科研環(huán)境想研究 DRM/KMS 的人手頭正好有 SM750 板卡。7.2 不太適合指望的場景以下場景就不要對 SM750 抱太多期望3D 游戲SM750 的 2D 定位決定了它不是為 OpenGL 游戲性能設計的。4K 高刷這次發(fā)布支持到 2048 寬和 2560x1080它并不等于支持所有 4K 高刷模式。芯片內部帶寬和顯存規(guī)格本來就不是為 4K 高刷準備的。多屏復雜組合如果產(chǎn)品需要多路 4K 輸出應該選更現(xiàn)代的顯示控制方案。完全不懂 Linux 的命令行環(huán)境DRM 驅動只解決 Linux 顯示鏈路底層能力系統(tǒng)集成和調試仍然需要基本的 Linux 操作知識。7.3 我的實際建議不管你是設備維護者還是產(chǎn)品開發(fā)人員這個發(fā)布都值得關注但不值得立刻把現(xiàn)有穩(wěn)定方案推翻。更穩(wěn)妥的做法是先拿一塊閑置板卡搭一個最小驗證環(huán)境確認驅動在你要用的內核版本上能編譯、加載、輸出。單獨接一臺 2560x1080 顯示器把模式列表、xrandr 切換、Qt 全屏顯示這三個環(huán)節(jié)驗證通過。之后再考慮是否把驅動納入生產(chǎn)鏡像。如果只是學習默認配置和文檔足夠入門。如果要投入生產(chǎn)就要把驅動版本、內核版本、發(fā)行版構建方式、輸出接口物理方案全都記錄歸檔。這樣后續(xù)內核升級或硬件批次變化時你有一個可以快速定位問題的基線。踩過幾次顯示棧的坑之后我最大的感受是很多黑屏和分辨率問題不是驅動能力不夠而是前置環(huán)境和輸入材料沒有處理干凈。先確認物理輸出鏈路再確認 EDID然后看內核日志最后才有必要去動源碼。這套順序在 SM750 上適用在其它 DRM 驅動上同樣適用。