簡(jiǎn)介OV5645 MIPI YUV攝像頭驅(qū)動(dòng)源碼包圍繞傳感器在MIPI YUV模式下的適配展開面向手機(jī)、平板等嵌入式設(shè)備的底層驅(qū)動(dòng)開發(fā)者解決攝像頭從硬件寄存器配置到上層應(yīng)用取流的完整鏈路問題。資源共4個(gè)文件包含3個(gè).h頭文件與1個(gè).c源文件分別承擔(dān)寄存器參數(shù)定義、攝像頭自定義參數(shù)、傳感器操作接口封裝以及MIPI YUV采集核心邏輯適合已有Linux/Android驅(qū)動(dòng)基礎(chǔ)、希望快速參考OV5645驅(qū)動(dòng)框架的學(xué)習(xí)者。包體大小僅40KB結(jié)構(gòu)精簡(jiǎn)目前已有583人學(xué)習(xí)。讀者可從代碼中梳理出傳感器初始化、數(shù)據(jù)解析、緩沖管理、同步信號(hào)處理與電源管理等多個(gè)關(guān)鍵模塊的寫法并了解錯(cuò)誤處理與上層API對(duì)接方式為后續(xù)移植或調(diào)試同類攝像頭驅(qū)動(dòng)提供直接可對(duì)照的參考實(shí)現(xiàn)。此外驅(qū)動(dòng)中對(duì)色彩校正、白平衡等圖像處理環(huán)節(jié)也保留了相應(yīng)接口有助于理解YUV數(shù)據(jù)在移動(dòng)攝像頭鏈路中的流轉(zhuǎn)與優(yōu)化思路。1. OV5645 MIPI YUV驅(qū)動(dòng)為什么ISP調(diào)優(yōu)和低延遲場(chǎng)景離不開YUV裸流做攝像頭驅(qū)動(dòng)這些年我遇到最多的一個(gè)誤解是OV5645 能輸出 JPEG那就直接拿 JPEG 流用吧省事。但真到了 ISP 調(diào)試、算法預(yù)處理、低延遲圖傳這類場(chǎng)景YUV 裸流幾乎是繞不開的。OV5645 的 MIPI 接口輸出 YUV422 格式時(shí)數(shù)據(jù)不經(jīng)過壓縮沒有 JPEG 的編碼延遲和塊噪聲每一幀拿到的都是傳感器經(jīng)過內(nèi)部 ISP 處理后的完整像素?cái)?shù)據(jù)這對(duì)做白平衡調(diào)試、降噪算法、或者把圖像直接喂給下游編解碼器的工程師來說價(jià)值比 JPEG 高得多。這篇筆記把我拆這個(gè)驅(qū)動(dòng)時(shí)走過的路整理出來從 V4L2 subdev 框架到 MIPI 鏈路參數(shù)再到抓流驗(yàn)證的完整閉環(huán)新人能按步驟上手老手可以直接跳去第四章看坑。2. 驅(qū)動(dòng)框架與上電時(shí)序把 V4L2 subdev 掛進(jìn) Linux Camera 子系統(tǒng)2.1 驅(qū)動(dòng)骨架與設(shè)備樹I2C 地址、電源引腳和時(shí)鐘要一次性配對(duì)OV5645 在 Linux 驅(qū)動(dòng)里通常實(shí)現(xiàn)為一個(gè) V4L2 異步 subdev掛在某個(gè) I2C 總線上通過 MIPI CSI-2 接口把數(shù)據(jù)送給 SoC 側(cè)的 controller。設(shè)備樹里最常出問題的是三個(gè)點(diǎn)I2C 地址、電源引腳極性、時(shí)鐘頻率。先看節(jié)點(diǎn)i2c2 { ov5645: camera3c { compatible ovti,ov5645; reg 0x3c; pinctrl-names default; pinctrl-0 ov5645_pinctrl; pwdn-gpios gpio1 14 GPIO_ACTIVE_LOW; reset-gpios gpio1 15 GPIO_ACTIVE_HIGH; clocks clk_cam_mclk; clock-names xvclk; assigned-clocks clk_cam_mclk; assigned-clock-rates 24000000; port { ov5645_mipi_ep: endpoint { remote-endpoint csi1_in; >static int ov5645_power_on(struct ov5645 *ov5645) { /* 1. PWDN 拉高讓 sensor 先進(jìn)入低功耗復(fù)位態(tài) */ gpiod_set_value_cansleep(ov5645-pwdn_gpio, 1); usleep_range(10000, 15000); /* 2. 使能 MCLK等待時(shí)鐘穩(wěn)定 */ clk_prepare_enable(ov5645-xvclk); usleep_range(5000, 10000); /* 3. RESET 拉低釋放 sensor 復(fù)位信號(hào) */ gpiod_set_value_cansleep(ov5645-reset_gpio, 0); usleep_range(20000, 30000); /* 4. 解除 PWDNsensor 開始內(nèi)部初始化 */ gpiod_set_value_cansleep(ov5645-pwdn_gpio, 0); usleep_range(20000, 20000); return 0; }這里每一步之間的延時(shí)都有實(shí)際意義PWDN 拉高后需要保持一段時(shí)間讓內(nèi)部電路放電復(fù)位MCLK 必須先穩(wěn)定再釋放 RESET否則 sensor 內(nèi)部的時(shí)鐘檢測(cè)邏輯會(huì)判定時(shí)鐘異常最后的 PWDN 拉低是整個(gè)上電動(dòng)作的最后一步拉早了 sensor 直接不干活。我見過有人把 RESET 和 PWDN 用一個(gè) GPIO 控制省了一個(gè)引腳但引入了上電時(shí)序的偶發(fā)問題這個(gè)操作不要學(xué)兩個(gè)信號(hào)必須獨(dú)立拉。2.3 寄存器讀寫通道SCCB 協(xié)議與 16 位地址的寫入細(xì)節(jié)OV5645 的控制通道是 SCCB 協(xié)議兼容 I2C但寄存器地址是 16 位的。這意味著每次寫一個(gè)寄存器要傳三個(gè)字節(jié)地址高字節(jié)、地址低字節(jié)、數(shù)據(jù)字節(jié)。驅(qū)動(dòng)里的寫寄存器函數(shù)一般長(zhǎng)這樣static int ov5645_write_reg(struct ov5645 *ov5645, u16 reg, u8 val) { struct i2c_client *client ov5645-i2c_client; u8 buf[3]; buf[0] (reg 8) 0xff; /* 寄存器地址高 8 位 */ buf[1] reg 0xff; /* 寄存器地址低 8 位 */ buf[2] val; /* 待寫入數(shù)據(jù) */ struct i2c_msg msg { .addr client-addr, .flags 0, .len 3, .buf buf, }; return i2c_transfer(client-adapter, msg, 1) 1 ? 0 : -EIO; }注意i2c_transfer的返回值是成功傳輸?shù)南?shù)量這里只有一條消息所以判斷是否等于 1。很多新手寫成if (ret 0)這樣遇到 NACK 時(shí)返回值可能為負(fù)但遇到總線異常返回 0 的情況就會(huì)漏判。批量初始化寄存器時(shí)我習(xí)慣把這些寫操作包一層static int ov5645_write_regs(struct ov5645 *ov5645, const struct ov5645_reg_value *regs, int count) { int i, ret; for (i 0; i count; i) { ret ov5645_write_reg(ov5645, regs[i].reg, regs[i].val); if (ret 0) { dev_err(ov5645-i2c_client-dev, write reg 0x%04x failed: %d\n, regs[i].reg, ret); return ret; } } return 0; }批量寫的中途失敗處理很重要調(diào)試時(shí)一眼就能看出是在哪條寄存器上掛的。另外 OV5645 的 SCCB 協(xié)議有的寄存器寫入后需要延時(shí)比如軟件復(fù)位寄存器0x3103寫完不能立刻繼續(xù)寫后面的寄存器需要等 sensor 內(nèi)部重啟完成這個(gè)問題第四章會(huì)展開說。3. MIPI CSI-2 鏈路配置YUV422 的 Data Type、Lane 速率與同步參數(shù)3.1 YUV422 在 MIPI 上的打包方式Data Type 0x1E 與人眼對(duì)色彩不敏感這件事MIPI CSI-2 協(xié)議里長(zhǎng)數(shù)據(jù)包需要一個(gè) Data Type 字段來標(biāo)識(shí)數(shù)據(jù)類型。OV5645 輸出 YUV422 時(shí)用的是 8-bit YUV422Data Type 為 0x1E。這個(gè)值必須在 SoC 側(cè)的 CSI controller 里和 sensor 側(cè)保持一致否則即使物理鏈路通著采集端也會(huì)把數(shù)據(jù)解析成一堆亂碼。YUV422 的采樣方式是每個(gè)像素保留完整亮度 Y色度 U/V 在水平方向每?jī)蓚€(gè)像素共享一組所以兩個(gè)像素占了 4 個(gè)字節(jié)平均每像素 16 bit。數(shù)據(jù)類型Data Type 值每像素位數(shù)典型場(chǎng)景8-bit YUV4220x1E16ISP 調(diào)優(yōu)、低延遲傳輸RGB8880x2424屏幕顯示直通RAW100x2B10后端自己做 ISPJPEG0x2C可變存儲(chǔ)、網(wǎng)絡(luò)傳輸選擇 YUV422 而不是 RAW10 或者 RGB888核心原因是壓縮率和畫質(zhì)的折中。YUV422 比 RGB888 省了三分之一的帶寬但在人眼感知上色彩差異幾乎不可見而 MIPI 鏈路的 lane 速率可以因此降下來降低 PCB 布線難度和信號(hào)完整性風(fēng)險(xiǎn)。如果你在后端還要做自己的 ISP 算法那才需要考慮 RAW10 輸出把 3A 算法完全握在自己手里。3.2 時(shí)鐘與 Lane 數(shù)計(jì)算從 PCLK 反推 MIPI 比特率別等信號(hào)失真了再查MIPI D-PHY 是源同步 DDR 接口數(shù)據(jù)在時(shí)鐘的上下邊沿都采樣所以鏈路帶寬的計(jì)算經(jīng)常把人繞暈。我習(xí)慣從 sensor 輸出的 PCLK 反推PCLK 96 MHz1280x96030fps 時(shí)典型值 每像素 bit 數(shù) 16YUV422 總比特率 PCLK × 16 1.536 Gbps 2-lane 配置下每 lane 比特率 768 Mbps D-PHY 工作在 DDR 模式PCLK 等效頻率 768 / 2 384 MHz這里的 384 MHz 就是 SoC 側(cè) CSI controller 需要配置的 MIPI 時(shí)鐘頻率。設(shè)備樹里link-frequencies配的/bits/ 64 336000000是我在另一塊板子上的實(shí)際值和上面 384 MHz 的差距是因?yàn)槟沁?PCLK 只有 84 MHz。關(guān)鍵點(diǎn)在于這兩個(gè)頻率必須匹配 sensor 的 PCLK而不是隨便抄一個(gè)模板。不匹配的表現(xiàn)通常是圖像有規(guī)律的花紋或者豎向條紋從波形上看就是采樣點(diǎn)落在了數(shù)據(jù)翻轉(zhuǎn)沿上。OV5645 的 PCLK 頻率受寄存器組控制核心是0x460c和0x460d這兩個(gè)字節(jié)組成的分頻系數(shù)。實(shí)際調(diào)試時(shí)我會(huì)這么做先用示波器量 MIPI clock lane 的頻率再對(duì)照 sensor 手冊(cè)的 PLL 計(jì)算公式確認(rèn)寄存器值。示波器量出來的頻率和計(jì)算值對(duì)不上優(yōu)先查 PLL 配置而不是懷疑示波器——這是我在這個(gè)項(xiàng)目上踩過的最深的一個(gè)坑后面細(xì)說。3.3 初始化序列組織把寄存器表拆成基礎(chǔ) 流控 效果三塊OV5645 的初始化寄存器表有幾百條全塞在一個(gè)數(shù)組里調(diào)試時(shí)想改一個(gè)參數(shù)就得在幾百行里翻效率太低。我后來把它拆成三段每段獨(dú)立可替換/* 1. 基礎(chǔ)配置sensor ID 確認(rèn)、時(shí)鐘 PLL、輸出格式 */ static const struct ov5645_reg_value ov5645_basic_settings[] { {0x3103, 0x11}, /* 軟件復(fù)位 */ {0x3103, 0x03}, {0x3008, 0x02}, /* 關(guān)閉流控 */ {0x3002, 0x1c}, /* 內(nèi)部 PLL 配置 */ {0x301b, 0xf0}, /* 分頻系數(shù) */ {0x3035, 0x21}, /* PLL 倍頻 */ {0x3036, 0x46}, /* PCLK 分頻 */ {0x3037, 0x08}, /* MIPI 分頻 */ }; /* 2. 流控配置分辨率、HTS/VTS、MIPI lane 與時(shí)鐘 */ static const struct ov5645_reg_value ov5645_stream_settings_1280x960[] { {0x3800, 0x00}, /* 水平起始 */ {0x3801, 0x00}, {0x3802, 0x00}, /* 垂直起始 */ {0x3803, 0x00}, {0x3804, 0x05}, /* 水平結(jié)束 1280 */ {0x3805, 0x00}, {0x3806, 0x03}, /* 垂直結(jié)束 960 */ {0x3807, 0xc0}, {0x3808, 0x05}, /* 實(shí)際輸出寬度 1280 */ {0x3809, 0x00}, {0x380a, 0x03}, /* 實(shí)際輸出高度 960 */ {0x380b, 0xc0}, {0x380c, 0x07}, /* HTS 1920 */ {0x380d, 0x80}, {0x380e, 0x04}, /* VTS 1250 */ {0x380f, 0xe2}, }; /* 3. 效果配置AEC/AGC/AWB 目標(biāo)值、飽和度、對(duì)比度 */ static const struct ov5645_reg_value ov5645_effect_settings[] { {0x3a0f, 0x30}, /* AEC 步長(zhǎng) */ {0x3a10, 0x28}, {0x3a1b, 0x30}, /* AGC 上限 */ {0x3a1e, 0x28}, {0x3a11, 0x60}, /* AEC 上限 */ {0x3a1f, 0x14}, /* AWB 色溫閾值 */ };這種拆分方式的收益在調(diào)試時(shí)體現(xiàn)得最明顯。圖像偏暗時(shí)我只需要?jiǎng)拥谌蔚?AEC/AGC 目標(biāo)值不用在一份大表里找哪個(gè)寄存器是管曝光的。HTS 和 VTS 在第二段改幀率直接算好寫入。PLL 相關(guān)在第一段換 sensor 板子時(shí)只要對(duì)著原理圖核對(duì) MCLK 再改倍頻系數(shù)就行。4. 避坑與常見問題排查五種典型翻車現(xiàn)場(chǎng)與處理記錄4.1 圖像全綠或滿屏豎條紋MIPI Data Type 與 Lane 數(shù)配置不一致現(xiàn)象是抓幀后圖像完全不可用有時(shí)整幀偏綠有時(shí)出現(xiàn)規(guī)律的豎向條紋但 dmesg 里沒有任何報(bào)錯(cuò)鏈路狀態(tài)看起來一切正常。原因是 sensor 這邊輸出 YUV422 但 SoC CSI controller 配置成了 RAW8或者 lane 數(shù)配了 4 但 sensor 實(shí)際只輸出了 2 lane數(shù)據(jù)被錯(cuò)誤切分。解決方法是先確認(rèn) Data Type 一致。sensor 側(cè)查寄存器0x4202它控制輸出格式Y(jié)UV422 時(shí)應(yīng)該是0x02。SoC 側(cè)查 CSI controller 的V4L2_MBUS_FMT_UYVY8_2X8或V4L2_MBUS_FMT_YUYV8_2X8枚舉值是否配對(duì)。Lane 數(shù)則用示波器量 clock lane 和數(shù)據(jù) lane 的實(shí)際翻轉(zhuǎn)2-lane 模式下只有 lane0 和 lane1 有數(shù)據(jù)lane2/lane3 應(yīng)該完全靜止。4.2 I2C probe 失敗讀不到 sensor IDPWDN 引腳極性配反現(xiàn)象是i2cdetect在地址 0x3c 上能看到設(shè)備但驅(qū)動(dòng)的 probe 函數(shù)里讀0x300a寄存器sensor ID應(yīng)為0x5645返回的都是0xff。原因是 PWDN GPIO 的 active 極性在設(shè)備樹里配反了。GPIO_ACTIVE_LOW表示低電平是有效狀態(tài)如果硬件上 PWDN 是高電平 power down正常工作時(shí)需要拉低。反過來的話sensor 一直在 power down 態(tài)I2C 地址雖然能探測(cè)到那是另一個(gè)器件或總線上拉但內(nèi)部邏輯完全不響應(yīng)。解決方法是核對(duì)原理圖確認(rèn) PWDN 有效電平是哪個(gè)然后改設(shè)備樹的pwdn-gpios標(biāo)志位。我一般會(huì)在上電函數(shù)里加一句動(dòng)態(tài)調(diào)試gpiod 拉完電平后讀回引腳狀態(tài)打印cat /sys/kernel/debug/gpio直接看實(shí)際電平省得反復(fù)改設(shè)備樹重啟。4.3 畫面偏暗偏色且調(diào)節(jié)曝光參數(shù)無反應(yīng)YUV 模式也要跑 3A 收斂現(xiàn)象是圖像能出來但整體亮度偏暗、白平衡明顯偏色手動(dòng)往寄存器里寫曝光增益值畫面沒有變化。原因是初始化序列里只配了輸出格式和分辨率AEC/AGC/AWB 的收斂算法被關(guān)掉了或者寄存器配置順序不對(duì)導(dǎo)致 3A 沒有真正啟動(dòng)。OV5645 的內(nèi)部 ISP 在 YUV 輸出時(shí)3A 是硬件自動(dòng)在跑的前提是相關(guān)寄存器使能位打開并且給了它足夠的幀數(shù)收斂。手動(dòng)寫寄存器值直接覆蓋了 3A 的目標(biāo)值但算法還在接管寫在前面會(huì)被收斂結(jié)果沖掉。解決方法是把曝光增益通過V4L2_CID_EXPOSURE和V4L2_CID_GAIN控制讓驅(qū)動(dòng)走 v4l2 的控制通道而不是直接寫寄存器這樣 3A 的自動(dòng)模式會(huì)被正確切換到手動(dòng)模式。另外檢查0x3a00寄存器AEC 使能位應(yīng)該是0x00代表自動(dòng)寫死為0x58之類的值就等于鎖死了算法。這個(gè)問題的本質(zhì)是繞過了驅(qū)動(dòng)框架去操作硬件后來我都是先清0x3a00再配手動(dòng)值順序問題解決。4.4 幀率不足只有標(biāo)稱的一半HTS 沒按 16 字節(jié)對(duì)齊現(xiàn)象是配置成 30fps實(shí)際抓流統(tǒng)計(jì)只有 15fps 左右數(shù)幀率能明顯感覺到卡頓。原因是 HTS 寄存器寫的值沒有滿足 sensor 內(nèi)部的 16 字節(jié)對(duì)齊要求。OV5645 的行同步信號(hào)需要 HTS 是某個(gè)對(duì)齊單位的整數(shù)倍寫錯(cuò)時(shí) sensor 每?jī)尚胁女a(chǎn)生一個(gè)完整行同步幀率直接腰斬。這是相當(dāng)隱蔽的一個(gè)坑因?yàn)榧拇嫫髦当旧砜雌饋砗侠?。解決方法是在寫 HTS 時(shí)強(qiáng)制對(duì)齊hts (hts / 16) * 16;再把對(duì)齊結(jié)果寫進(jìn)0x380c和0x380d兩個(gè)字節(jié)。1280x96030fps 這個(gè)分辨率下HTS 取 1920 正好是 16 的倍數(shù)但如果改到其他分辨率計(jì)算時(shí)必須手動(dòng)對(duì)齊不能直接拿公式算出來的值往里寫。4.5 冷啟動(dòng)偶發(fā)抓不到流MCLK 穩(wěn)定時(shí)間不足現(xiàn)象是板子斷電再上電后驅(qū)動(dòng)加載正常、I2C 通信正常、寄存器初始化全部返回成功但stream on之后完全沒有數(shù)據(jù)幀到達(dá)而且不是每次都復(fù)現(xiàn)十次里有兩三次。原因排查最后定位到上電時(shí)序的 MCLK 延時(shí)。斷電再上電時(shí)晶振或 SoC 的時(shí)鐘輸出需要更長(zhǎng)的穩(wěn)定時(shí)間我最初的代碼里 MCLK 使能后只延時(shí)了 1ms在常溫下夠用但環(huán)境溫度變化后時(shí)鐘源起振變慢sensor 內(nèi)部的 PLL 鎖定失敗導(dǎo)致 MIPI 鏈路遲遲不輸出數(shù)據(jù)。解決方法是把 MCLK 穩(wěn)定延時(shí)從usleep_range(1000, 2000)加到usleep_range(5000, 10000)并且在 stream on 之前追加一次0x3008寄存器軟復(fù)位確保 sensor 狀態(tài)機(jī)從頭開始跑。從那以后我在上電函數(shù)里保留了打印時(shí)鐘狀態(tài)的習(xí)慣每次 crash 都先確認(rèn) sensor 側(cè) PLL 鎖定寄存器0x3028讀取到的值。5. 抓流與驗(yàn)證從 dmesg 到像素級(jí)確認(rèn) YUV 數(shù)據(jù)的完整閉環(huán)5.1 用 dmesg 和 v4l2-ctl 確認(rèn)鏈路存活驅(qū)動(dòng) probe 成功只是第一步鏈路是否真正通需要一層層驗(yàn)證。先看內(nèi)核日志確認(rèn) subdev 注冊(cè)成功dmesg | grep -i ov5645然后列設(shè)備節(jié)點(diǎn)確認(rèn) media controller 拓?fù)湔4l2-ctl --list-devices media-ctl -p -d /dev/media0這兩條命令能確認(rèn) sensor 和 CSI controller 之間的 pad 連接是否正確。我遇到過驅(qū)動(dòng)加載正常但 media graph 里 csi 和 sensor 沒有連接的情況單獨(dú)設(shè)置格式時(shí)提示-ENODEV。確認(rèn)鏈路后再設(shè)置格式并開始抓幀v4l2-ctl -d /dev/video0 --set-fmt-videowidth1280,height960,pixelformatYUYV v4l2-ctl -d /dev/video0 --stream-mmap --stream-count1 --stream-to/tmp/frame.raw--stream-count1只抓一幀--stream-to把裸數(shù)據(jù)存文件。這一幀 YUYV 數(shù)據(jù)的大小應(yīng)該是1280 * 960 * 2 2457600字節(jié)如果文件大小不對(duì)說明 DMA 和 sink 的格式配置有問題需要回頭檢查 v4l2 的bytesperline和sizeimage參數(shù)。5.2 用 Python 把 YUV422 轉(zhuǎn)成 RGB 做像素級(jí)確認(rèn)文件抓出來了怎么確認(rèn)它不是一片噪聲用 v4l2-ctl 的--stream-to抓的是裸 YUYV 數(shù)據(jù)直接用圖片查看器打不開需要自己解析。我一般用一小段 Python 快速驗(yàn)證import numpy as np from PIL import Image W, H 1280, 960 raw np.fromfile(/tmp/frame.raw, dtypenp.uint8) assert raw.size W * H * 2, f文件大小異常: {raw.size} # YUYV 交錯(cuò)排列: Y0 U0 Y1 V0 Y2 U1 Y3 V1 ... yuyv raw.reshape(H, W, 2) y yuyv[:, :, 0] # 偶數(shù)位置是 Y uv yuyv[:, :, 1] # 奇數(shù)位置是 UV 交錯(cuò) u uv[:, ::2].repeat(2, axis1) # 水平復(fù)制恢復(fù) 4:2:2 v uv[:, 1::2].repeat(2, axis1) # BT.601 矩陣做 YUV - RGB rgb np.empty((H, W, 3), dtypenp.float32) rgb[:, :, 0] y 1.402 * (v.astype(np.float32) - 128) rgb[:, :, 1] y - 0.344 * (u.astype(np.float32) - 128) - 0.714 * (v.astype(np.float32) - 128) rgb[:, :, 2] y 1.772 * (u.astype(np.float32) - 128) rgb np.clip(rgb, 0, 255).astype(np.uint8) Image.fromarray(rgb).save(/tmp/frame.png)跑完打開圖片如果畫面內(nèi)容正常就是鏈路全通了。如果色彩整體偏綠偏紫優(yōu)先懷疑U和V取反了如果畫面有明顯的下采樣鋸齒說明u平面的水平復(fù)制邏輯沒寫對(duì)。我見過有人在這一步直接拿ffmpeg轉(zhuǎn)格式雖然能出圖但出問題時(shí)分不清是驅(qū)動(dòng)問題還是轉(zhuǎn)換參數(shù)問題還是自己解析一遍最可靠。從那以后我每次調(diào)完驅(qū)動(dòng)都強(qiáng)制走一遍這個(gè)流程dmesg 看枚舉、media-ctl 查拓?fù)洹螏ト?、Python 轉(zhuǎn) RGB四步確認(rèn)完才敢提交代碼希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取