TODO 列表

本節包含核心 DRM 圖形子系統中一些較小的清理任務列表，它們可作為新手專案，或在悠閒的雨天完成。

難度

為了方便起見，任務分為不同等級

入門：DRM 子系統入門的好任務。

中級：需要一些 DRM 子系統工作經驗，或一些特定 GPU/顯示圖形知識的任務。對於除錯問題，最好有相關的硬體（或設定好的虛擬驅動程式）可供測試。

高階：需要相當好地理解 DRM 子系統和圖形主題的棘手任務。通常需要相關的硬體進行開發和測試。

專家：僅在您已成功完成一些棘手的重構並且是特定領域的專家時才嘗試這些任務

子系統範圍重構

移除自定義 dumb_map_offset 實現

所有基於 GEM 的驅動程式都應使用 drm_gem_create_mmap_offset()。審查每個單獨的驅動程式，確保它能與通用實現配合使用（各種實現中有很多過時的鎖定遺留問題），然後將其移除。

聯絡人：Simona Vetter，相關驅動維護者

級別：中級

將現有 KMS 驅動程式轉換為原子模式設定

3.19 版本擁有原子模式設定介面和輔助函式，因此驅動程式現在可以進行轉換。Wayland 或 Android 上的 Surfaceflinger 等現代合成器確實需要原子模式設定介面，因此這一切都關乎光明的未來。

有一個原子轉換指南[1]，您只需一個尚未轉換的 GPU 即可。“原子模式設定設計概述”系列[2] [3]在 LWN.net 上可能也會有所幫助。

作為轉換的一部分，驅動程式還需要轉換為通用平面（這意味著將主平面和游標暴露為正確的平面物件）。但這透過直接使用新的原子輔助驅動回撥更容易實現。

聯絡人：Simona Vetter，相關驅動維護者

級別：高階

清理平面周圍的裁剪座標混淆

我們有一個輔助函式 drm_plane_helper_check_update() 可以正確處理此問題，但它沒有被一致使用。這應該得到修復，最好是在原子輔助函式中（然後驅動程式移到裁剪座標）。可能輔助函式也應該從 drm_plane_helper.c 移到原子輔助函式，以避免混淆——該檔案中的其他輔助函式都是已棄用的舊版輔助函式。

聯絡人：Ville Syrjälä, Simona Vetter, 驅動程式維護者

級別：高階

改進平面 atomic_check 輔助函式

除了上面提到的裁剪座標外，當前的輔助函式還有一些不理想的地方

  • 無論平面啟用還是停用，都會呼叫 drm_plane_helper_funcs->atomic_check。充其量這似乎會混淆驅動程式，最壞的情況是當平面在沒有 CRTC 的情況下停用時，它們會崩潰。唯一的特殊處理是重置平面狀態結構中的值，這應該移到 drm_plane_funcs->atomic_duplicate_state 函式中。

  • 一旦完成，輔助函式就可以停止為停用的平面呼叫 ->atomic_check。

  • 然後我們可以遍歷所有驅動程式，並移除對 plane_state->fb 和 plane_state->crtc 或多或少混淆的檢查。

聯絡人：Simona Vetter

級別：高階

將早期原子驅動程式轉換為非同步提交輔助函式

在原子模式設定輔助功能推出的第一年，它們不支援非同步/非阻塞提交，每個驅動程式都必須手動實現。現在這已修復，但仍有一堆現有驅動程式可以輕鬆轉換為新的基礎設施。

輔助功能的一個問題是它們要求驅動程式正確處理原子提交的完成事件。但修復這些錯誤無論如何都是好的。

與此有些相關的是 legacy_cursor_update 技巧，它應該在仍然檢視該標誌的驅動程式中，用輔助功能中新的 atomic_async_check/commit 功能取代。

聯絡人：Simona Vetter，相關驅動維護者

級別：高階

重新命名 drm_atomic_state

KMS 框架對 state 概念使用了兩個略有不同的定義。對於給定物件（平面、CRTC、編碼器等，即 drm_$OBJECT_state），狀態是該物件的整個狀態。然而，在裝置級別，drm_atomic_state 指的是有限數量物件的狀態更新。

該狀態不是整個裝置狀態，而只是該裝置中某些物件的完整狀態。這會讓新手感到困惑，drm_atomic_state 應該重新命名為更清晰的名稱，例如 drm_atomic_commit。

除了重新命名結構本身，這還意味著重新命名一些相關函式（drm_atomic_state_alloc、drm_atomic_state_get、drm_atomic_state_put、drm_atomic_state_init、__drm_atomic_state_free 等）。

聯絡人：Maxime Ripard <mripard@kernel.org>

級別：高階

原子 KMS 的影響

drm_atomic_helper.c 提供了一批函式，這些函式在新的原子驅動程式介面之上實現了舊版 IOCTL。這對於驅動程式的逐步轉換非常有用，但不幸的是語義不匹配有點嚴重。因此，還需要一些後續工作來調整函式介面以修復這些問題

  • 原子操作需要鎖獲取上下文。目前，這透過一些糟糕的技巧隱式傳遞，並且它也在後臺用 GFP_NOFAIL 分配。所有舊版路徑都需要開始在堆疊上顯式分配獲取上下文，然後也將其顯式傳遞給驅動程式，以便舊版-在-原子函式可以使用它們。

    除了一些驅動程式碼，這已經完成。此任務應透過在 drm_modeset_lock_all() 中新增 WARN_ON(!drm_drv_uses_atomic_modeset) 來完成。

  • 許多 vtable 鉤子現在位於錯誤的位置：DRM 在核心 vfunc 表（名為 drm_foo_funcs）之間進行拆分，這些表用於實現使用者空間 ABI。然後是輔助庫的可選鉤子（名為 drm_foo_helper_funcs），它們純粹用於內部使用。其中一些鉤子應該從 _funcs 移到 _helper_funcs，因為它們不屬於核心 ABI。在 drm_crtc.h 中，每個此類情況的 kerneldoc 中都有一個 FIXME 註釋。

聯絡人：Simona Vetter

級別：中級

從 GEM 驅動程式中移除 dev->struct_mutex

dev->struct_mutex 是舊版 DRM 大鎖，它感染了所有東西。現在在現代驅動程式中，唯一強制使用的部分是序列化 GEM 緩衝區物件銷燬。不幸的是，這意味著驅動程式必須根據上下文跟蹤該鎖並呼叫 unreference 或 unreference_locked。

自核心 4.8 以來，核心 GEM 不再需要 struct_mutex，並且對於完全 struct_mutex 免費的驅動程式，有一個 GEM 物件 free 回撥。

對於需要 struct_mutex 的驅動程式，它應該替換為驅動程式私有鎖。棘手的部分是 BO 自由函式，因為它們不能再可靠地獲取該鎖。相反，狀態需要用合適的從屬鎖保護，或者一些清理工作推送到工作執行緒。對於效能關鍵型驅動程式，使用更細粒度的每緩衝區物件和每上下文鎖定方案可能更好。目前只有 msm 和 i915 驅動程式使用 struct_mutex。

聯絡人：Simona Vetter，相關驅動維護者

級別：高階

將緩衝區物件鎖定移動到 dma_resv_lock()

許多驅動程式都有自己的每物件鎖定方案，通常使用 mutex_lock()。這會導致緩衝區共享出現各種問題，因為取決於哪個驅動程式是匯出者和匯入者，鎖定層次結構是反向的。

為了解決這個問題，我們需要一個標準的每物件鎖定機制，即 dma_resv_lock()。此鎖需要作為最外層鎖呼叫，並移除所有其他驅動程式特定的每物件鎖。問題是，由於 struct dma_buf 緩衝區共享，推出實際的鎖定契約更改是一個標誌日。

級別：專家

將日誌記錄轉換為帶 drm_device 引數的 drm_* 函式

對於可能存在多個例項的驅動程式，有必要在日誌中區分它們。由於 DRM_INFO/WARN/ERROR 不這樣做，驅動程式使用 dev_info/warn/err 來進行區分。我們現在有 drm 列印函式的 drm_* 變體，因此我們可以開始將這些驅動程式轉換回使用 drm 格式的特定日誌訊息。

在開始此轉換之前，請聯絡相關維護者，以確保您的工作將被合併——並非所有人都同意 DRM dmesg 宏更好。

聯絡人：Sean Paul，您計劃轉換的驅動程式的維護者

級別：入門

將驅動程式轉換為使用簡單模式設定暫停/恢復

大多數使用 drm_atomic_helper_suspend/resume() 的驅動程式（i915 和 nouveau 除外）可能可以轉換為使用 drm_mode_config_helper_suspend/resume()。此外，在較舊的原子模式設定驅動程式中，仍然存在開放編碼的原子暫停/恢復程式碼版本。

聯絡人：您計劃轉換的驅動程式的維護者

級別：中級

在沒有 fbdev 的情況下重新實現 drm_fbdev_fb_ops 中的函式

drm_fbdev_fb_ops 中的許多回調函式可以受益於在不依賴 fbdev 模組的情況下重寫。一些輔助函式可以進一步受益於使用 struct iosys_map 而不是原始指標。

聯絡人：Thomas Zimmermann <tzimmermann@suse.de>，Simona Vetter

級別：高階

基準測試和最佳化 blitting 和格式轉換函式

快速繪製到顯示記憶體對於許多應用程式的效能至關重要。

至少在 x86-64 上，sys_imageblit() 明顯比 cfb_imageblit() 慢，儘管兩者使用相同的位塊傳輸演算法，並且後者是為 I/O 記憶體編寫的。結果表明 cfb_imageblit() 使用 movl 指令，而 sys_imageblit 顯然沒有。這似乎是 gcc 最佳化器的問題。DRM 的格式轉換輔助函式可能也存在類似問題。

基準測試並最佳化 fbdev 的 sys_() 輔助函式和 DRM 的格式轉換輔助函式。在可以進一步最佳化的情況下，也許可以實現不同的演算法。對於微最佳化，顯式使用 movl/movq 指令。這可能需要特定於架構的輔助函式（例如，storel() storeq()）。

聯絡人：Thomas Zimmermann <tzimmermann@suse.de>

級別：中級

drm_framebuffer_funcs 和 drm_mode_config_funcs.fb_create 清理

更多的驅動程式可以切換到 drm_gem_framebuffer 輔助函式。各種障礙

  • 首先需要切換到使用 drm_atomic_helper_dirtyfb 的通用髒跟蹤程式碼（例如 qxl）。

  • 需要切換到 drm_fbdev_generic_setup()，否則許多自定義 fb 設定程式碼無法刪除。

  • 需要切換到 drm_gem_fb_create()，因為現在 drm_gem_fb_create() 會檢查原子驅動程式的有效格式。

  • 許多驅動程式子類化了 drm_framebuffer，我們需要一個與各種 drm_gem_fb_create 函式相容的嵌入版本。可能根據需要命名為 drm_gem_fb_create/_with_dirty/_with_funcs。

聯絡人：Simona Vetter

級別：中級

通用 fbdev defio 支援

fbdev 核心中的 defio 支援程式碼有一些非常具體的要求，這意味著驅動程式需要有一個用於 fbdev 的特殊幀緩衝。主要問題是它使用了 struct page 本身中的一些欄位，這會破壞 shmem gem 物件（以及其他東西）。為了支援 defio，受影響的驅動程式需要使用影子緩衝區，這可能會增加 CPU 和記憶體開銷。

可能的解決方案是在 drm fbdev 模擬中編寫我們自己的 defio mmap 程式碼。它需要完全封裝現有的 mmap ops，在完成防寫/mkwrite 技巧後轉發所有內容

  • 在 drm_fbdev_fb_mmap 輔助函式中，如果我們需要 defio，則將預設頁面保護更改為防寫，如下所示

    vma->vm_page_prot = pgprot_wrprotect(vma->vm_page_prot);

  • 設定 mkwrite 和 fsync 回撥，其實現類似於核心 fbdev defio 內容。這些都應該在純 ptes 上工作，它們實際上不需要 struct page。uff。這些都應該在純 ptes 上工作，它們實際上不需要 struct page。

  • 在單獨的結構中跟蹤髒頁（每個頁面一位的位域應該可以），以避免破壞 struct page。

最好也為此新增一些 igt 測試用例。

聯絡人：Simona Vetter，Noralf Tronnes

級別：高階

聯結器註冊/登出修復

  • 對於大多數聯結器，直接從驅動程式碼呼叫 drm_connector_register/unregister 是無操作的，drm_dev_register/unregister 已經處理了這個問題。我們可以刪除所有這些呼叫。

  • 對於 dp 驅動程式來說，情況有點複雜，因為我們在呼叫 drm_dp_aux_register 時需要註冊聯結器。透過改為呼叫 drm_dp_aux_init，並將實際註冊移動到 kerneldoc 中建議的 late_register 回撥來解決此問題。

級別：中級

移除載入/解除安裝回撥

結構體 &drm_driver 中的 load/unload 回撥函式非常像中間層，此外由於歷史原因，它們在設定 &drm_driver 結構和呼叫 drm_dev_register() 之間弄錯了順序（而且我們無法修復）。

  • 重新設計驅動程式，使其不再使用載入/解除安裝回撥，而是將載入/解除安裝序列直接編碼到驅動程式的 probe 函式中。

  • 一旦所有驅動程式都已轉換，就移除載入/解除安裝回撥。

聯絡人：Simona Vetter

級別：中級

將 drm_detect_hdmi_monitor() 替換為 drm_display_info.is_hdmi

一旦 EDID 被解析，顯示器的 HDMI 支援資訊就可以透過 drm_display_info.is_hdmi 獲得。許多驅動程式仍然呼叫 drm_detect_hdmi_monitor() 來獲取相同的資訊，效率較低。

審計每個呼叫 drm_detect_hdmi_monitor() 的驅動程式，並在適用時切換到 drm_display_info.is_hdmi。

聯絡人：Laurent Pinchart，相關驅動維護者

級別：中級

合併自定義驅動模式設定屬性

在原子模式設定出現之前，許多驅動程式都在建立自己的屬性。原子模式設定帶來了其中一個要求，即不應使用自定義的、特定於驅動程式的屬性。

對於此任務，我們的目標是引入核心輔助函式或重用現有函式（如果可用）

一個未經確認的快速示例列表。

引入核心輔助函式：- 音訊 (amdgpu, intel, gma500, radeon) - 亮度, 對比度等 (armada, nouveau) - 僅疊加層 (?) - 廣播 rgb (gma500, intel) - 色度鍵 (armada, nouveau, rcar) - 僅疊加層 (?) - 抖動 (amdgpu, nouveau, radeon) - 驅動程式之間不同 - underscan 系列 (amdgpu, radeon, nouveau)

已在核心中：- 色彩空間 (sti) - 電視格式名稱，增強 (gma500, intel) - 電視過掃描，邊距等 (gma500, intel) - zorder (omapdrm) - 與 zpos 相同 (?)

聯絡人：Emil Velikov，相關驅動維護者

級別：中級

在整個程式碼庫中使用 struct iosys_map

指向共享裝置記憶體的指標儲存在 struct iosys_map 中。每個例項都知道它是指向系統記憶體還是 I/O 記憶體。大多數 DRM 範圍的介面已轉換為使用 struct iosys_map，但實現通常仍使用原始指標。

任務是在合理的地方使用 struct iosys_map。

聯絡人：Thomas Zimmermann <tzimmermann@suse.de>，Christian König，Simona Vetter

級別：中級

審查所有驅動程式，確保 struct drm_mode_config.{max_width,max_height} 設定正確

struct drm_mode_config.{max_width,max_height} 中的值描述了支援的最大幀緩衝大小。它是虛擬螢幕大小，但許多驅動程式將其視為物理解析度的限制。

最大寬度取決於硬體的最大掃描線間距。最大高度取決於可定址影片記憶體的數量。審查所有驅動程式，以將欄位初始化為正確的值。

聯絡人：Thomas Zimmermann <tzimmermann@suse.de>

級別：中級

在所有 fbdev 驅動程式中請求記憶體區域

舊/古老的 fbdev 驅動程式沒有正確請求它們的記憶體。遍歷這些驅動程式並新增程式碼以請求驅動程式使用的記憶體區域。這需要新增對 request_mem_region()、pci_request_region() 或類似函式的呼叫。儘可能使用輔助函式進行託管清理。有問題的地方包括具有 VGA 等獨佔範圍的硬體。VGA16fb 不按預期請求範圍。驅動程式在這方面非常糟糕，並且過去 DRM 和 fbdev 驅動程式之間存在衝突。儘管如此，這是正確的做法。

聯絡人：Thomas Zimmermann <tzimmermann@suse.de>

級別：入門

移除驅動程式對 FB_DEVICE 的依賴

許多 fbdev 驅動程式透過 sysfs 提供屬性，因此依賴於 CONFIG_FB_DEVICE 的選擇。審查每個驅動程式，並嘗試使任何對 CONFIG_FB_DEVICE 的依賴可選。至少，驅動程式中的相應程式碼可以透過 ifdef CONFIG_FB_DEVICE 進行條件化。並非所有驅動程式都能夠刪除 CONFIG_FB_DEVICE。

聯絡人：Thomas Zimmermann <tzimmermann@suse.de>

級別：入門

移除 panel-simple 和 panel-edp 中 remove/shutdown 中的 disable/unprepare

從 commit d2aacaf07395（“drm/panel: 在 drm_panel 中檢查是否已準備/啟用”）開始，我們在 drm_panel 核心中有一個檢查，以確保沒有人重複呼叫 prepare/enable/disable/unprepare。最終，這可能應該變成 WARN_ON() 或以某種方式使其更響亮。

目前，我們預計在使用 panel-simple 和 panel-edp 時，仍然可能會在 drm_panel 核心中遇到警告。由於這些面板驅動程式與許多不同的 DRM 模式設定驅動程式一起使用，因此它們在關閉時仍然會額外努力地停用/取消準備面板本身。具體來說，如果面板驅動程式在 DRM 模式設定驅動程式 _之前_ 關閉，並且 DRM 模式設定驅動程式在其自己的 shutdown() 回撥中正確呼叫 drm_atomic_helper_shutdown()，我們仍然可能會遇到這些警告。在這種情況下，可以透過使用類似裝置連結的東西來避免警告，以確保面板在 DRM 模式設定驅動程式之後關閉。

一旦所有 DRM 模式設定驅動程式都已知會正確關閉，就應該移除 panel-simple 和 panel-edp 中 remove/shutdown 中多餘的 disable/unprepare 呼叫，並將此 TODO 項標記為完成。

聯絡人：Douglas Anderson <dianders@chromium.org>

級別：中級

逐步淘汰 mipi_dsi_*_write_seq()

宏 mipi_dsi_generic_write_seq() 和 mipi_dsi_dcs_write_seq() 不直觀，因為如果出現錯誤，它們會從呼叫者的函式中返回。我們應該將所有呼叫者改為使用 mipi_dsi_generic_write_seq_multi() 和 mipi_dsi_dcs_write_seq_multi() 宏。

一旦所有呼叫者都已轉換，這些宏及其呼叫的函式 mipi_dsi_generic_write_chatty() 和 mipi_dsi_dcs_write_buffer_chatty() 可能就可以移除了。或者，如果有人覺得 _multi() 變體對於某些用例來說過於冗餘，我們可以保留 mipi_dsi_*_write_seq() 變體，但更改它們不再從呼叫者處返回。

聯絡人：Douglas Anderson <dianders@chromium.org>

級別：入門

核心重構

使 panic 處理工作

這是一項非常多樣的任務，包含許多小部分

  • 恐慌路徑目前無法測試，導致不斷中斷。這裡的主要問題是恐慌可能從 hardirq 上下文觸發，因此所有與恐慌相關的回撥都可以在 hardirq 上下文執行。如果我們可以透過 drm debugfs 檔案觸發呼叫來測試 fbdev 輔助程式碼和驅動程式程式碼，那就太棒了。hardirq 上下文可以透過使用 IPI 到本地處理器來實現。

  • 不同恐慌處理程式之間存在巨大混亂。DRM fbdev 模擬輔助程式有自己的（早已移除），但除此之外，fbcon 程式碼本身也有一個。我們需要確保它們停止相互干擾。這透過在 DRM fbdev 模擬輔助程式的各種入口點檢查 oops_in_progress 來解決。這裡更乾淨的方法是將 fbcon 切換到 執行緒 printk 支援。

  • drm_can_sleep() 是一團糟。它在正常操作中隱藏了真正的 bug，並且不是恐慌路徑的完整解決方案。我們需要確保它只在真正發生恐慌時才返回 true，並修復所有後續問題。

  • 恐慌處理程式絕不能休眠，這也意味著它永遠不能 mutex_lock()。它也不能無條件地獲取任何其他鎖，甚至自旋鎖（因為 NMI 和 hardirq 也會導致恐慌）。我們需要確保不呼叫此類路徑，或者嘗試鎖定所有內容。這確實很棘手。

  • 一個乾淨的解決方案是在 KMS 中完全獨立的恐慌輸出支援，繞過當前的 fbcon 支援。參見 [PATCH v2 0/3] drm: Add panic handling。

  • 將實際的 oops 和前面的 dmesg 編碼到 QR 碼中可能有助於解決令人頭疼的“重要內容已滾動過去”問題。參見 [RFC][PATCH] Oops messages transfer using QR codes 以獲取可重用的一些示例程式碼。

聯絡人：Simona Vetter

級別：高階

清理 debugfs 支援

它存在一些問題

  • 將驅動程式轉換為支援 drm_debugfs_add_files() 函式而不是 drm_debugfs_create_files() 函式。

  • 透過為聯結器和 CRTC 也推出相同的 debugfs 預註冊基礎設施來改進後期註冊 debugfs。這樣，驅動程式就不再需要將其設定程式碼分成 init 和 register。

  • 我們可能希望在核心中直接支援 crtc/聯結器以及其他 kms 物件上的 debugfs 檔案。這些物件的 func 中甚至有 drm_print 支援來轉儲 kms 狀態，所以一切都在那裡。然後 ->show() 函式顯然應該為您提供指向正確物件的指標。

  • 我們擁有的 drm_driver->debugfs_init 鉤子只是舊中間層載入序列的遺物。DRM debugfs 應該更像 sysfs，您可以在任何時候為物件建立屬性/檔案，核心負責在註冊/登出時釋出/取消釋出所有檔案。驅動程式不應該擔心這些技術細節，修復此問題（以及 drm_minor->drm_device 移動）將允許我們移除 debugfs_init。

聯絡人：Simona Vetter

級別：中級

物件生命週期修復

這裡有兩個相關問題

  • 清理各種 ->destroy 回撥，這些回撥通常都是相同的簡單程式碼。

  • 許多驅動程式錯誤地使用 devm_kzalloc 分配 DRM 模式設定物件，這導致驅動程式解除安裝時出現使用後釋放問題。即使對於整合在 SoC 上的硬體驅動程式，由於 EPROBE_DEFERRED 回退，這也可能是嚴重的問題。

這兩個問題都可以透過切換到 drmm_kzalloc() 以及提供的各種便捷包裝器來解決，例如 drmm_crtc_alloc_with_planes()、drmm_universal_plane_alloc() 等等。

聯絡人：Simona Vetter

級別：中級

從 dma-buf 匯入中移除自動頁面對映

匯入 dma-bufs 時，dma-buf 和 PRIME 框架會自動將匯入的頁面對映到匯入者的 DMA 區域。drm_gem_prime_fd_to_handle() 和 drm_gem_prime_handle_to_fd() 要求匯入者即使從不執行實際的裝置 DMA，而只通過 dma_buf_vmap() 進行 CPU 訪問，也要呼叫 dma_buf_attach()。這對於不支援 DMA 操作的 USB 裝置來說是一個問題。

為了解決這個問題，應從緩衝區共享程式碼中移除自動頁面對映。修復這個問題有點複雜，因為匯入/匯出快取也與 &drm_gem_object.import_attach 繫結。同時，只要 USB 主機控制器裝置支援 DMA，我們就可以透過找出 USB 主機控制器裝置來解決 USB 裝置的問題。否則，匯入仍然可能不必要地失敗。

聯絡人：Thomas Zimmermann <tzimmermann@suse.de>，Simona Vetter

級別：高階

更好的測試

使用核心單元測試 (KUnit) 框架新增單元測試

KUnit 為 Linux 核心中的單元測試提供了一個通用框架。擁有一套測試套件可以更早地發現迴歸。

第一個單元測試的好候選者是 drm_format_helper.c 中的格式轉換輔助函式。

聯絡人：Javier Martinez Canillas <javierm@redhat.com>

級別：中級

清理和文件化以前的 selftests 套件

一些 KUnit 測試套件（drm_buddy、drm_cmdline_parser、drm_damage_helper、drm_format、drm_framebuffer、drm_dp_mst_helper、drm_mm、drm_plane_helper 和 drm_rect）是以前的 selftest 套件，它們在 KUnit 首次引入時就已轉換為 KUnit。

這些套件文件不足，並且目標與單元測試可能有所不同。嘗試識別這些套件中的每個測試實際測試什麼，是否適合單元測試，如果不是則刪除，如果是則文件化，這將非常有幫助。

聯絡人：Maxime Ripard <mripard@kernel.org>

級別：中級

為 DRM 啟用 trinity

並修復其產生的問題。應該會非常有趣……

級別：高階

使 i-g-t 中的 KMS 測試通用化

i915 驅動團隊為 i915 DRM 驅動維護了一個廣泛的測試套件，包括大量針對模式設定 API 邊緣情況的測試用例。如果這些測試（至少那些不依賴於 Intel 特定 GEM 功能的測試）能夠執行在任何 KMS 驅動程式上，那將是極好的。

在非 i915 上執行 i-g-t 測試的基礎工作已經完成，現在缺少的是大規模轉換。對於模式設定測試，我們還需要一些基礎設施來使用啞緩衝區進行無平鋪緩衝區，以便能夠執行所有非 i915 特定模式設定測試。

級別：高階

擴充套件虛擬測試驅動程式 (VKMS)

更多詳細資訊請參閱 VKMS 文件。這是一個理想的實習任務，因為它只需要一個虛擬機器，並且可以根據可用時間進行調整。

級別：詳見

背光重構

背光碟機動有三重啟用/停用狀態，這有點過度。計劃修復此問題

  1. 在所有地方推出 backlight_enable() 和 backlight_disable() 輔助函式。這已經開始了。

  2. 總而言之，只看上述輔助函式設定的三個狀態位中的一個。

  3. 移除另外兩個狀態位。

聯絡人：Simona Vetter

級別：中級

驅動程式特定

AMD DC 顯示驅動程式

AMD DC 是從 Vega 開始的 AMD 裝置的顯示驅動程式。清理工作已經取得了很大進展，但仍有大量工作要做。

任務詳情請參閱 drivers/gpu/drm/amd/display/TODO。

聯絡人：Harry Wentland，Alex Deucher

啟動畫面

現在已經有支援內部 DRM 客戶端的機制，這使得可以繼續進行之前因針對 fbdev 編寫而被拒絕的啟動畫面工作。

聯絡人：Sam Ravnborg

級別：高階

多內部面板裝置的亮度處理

在 x86/ACPI 裝置上，可以有多個背光韌體介面：（ACPI）影片、供應商特定和其他。以及 KMS 驅動程式直接/本機（PWM）暫存器程式設計。

為了處理這個問題，在 x86/ACPI 上使用的背光碟機動程式會呼叫 acpi_video_get_backlight_type()，它具有啟發式（+怪癖）來選擇要使用的背光介面；並且與返回型別不匹配的背光碟機動程式將不會註冊自己，以便只註冊一個背光裝置（在單個 GPU 設定中，見下文）。

目前這或多或少地假設系統上只有一個（內部）面板。

在具有 2 個面板的系統上，這可能是一個問題，具體取決於 acpi_video_get_backlight_type() 選擇的介面

  1. 原生：在這種情況下，KMS 驅動程式應該知道哪個背光裝置屬於哪個輸出，因此一切都應該正常工作。

  2. 影片：這確實支援控制多個背光，但需要做一些工作才能獲得輸出 <-> 背光裝置對映

以上假設兩個面板都需要相同的背光介面型別。在具有多個面板的系統上，如果兩個面板需要不同型別的控制，情況就會崩潰。例如，一個面板需要 ACPI 影片背光控制，而另一個面板使用原生背光控制。目前在這種情況下，根據 acpi_video_get_backlight_type() 的返回值，只會註冊兩個所需背光裝置中的一個。

如果這種情況（理論上）出現，那麼支援它將需要一些工作。一個可能的解決方案是將裝置和聯結器名稱傳遞給 acpi_video_get_backlight_type()，以便它可以處理這個問題。

注意，在某種程度上，我們已經有使用者空間看到兩個面板的情況，在帶有多路複用器的雙 GPU 筆記型電腦設定中。在這些系統上，我們可能會看到兩個原生背光裝置；或兩個原生背光裝置。

使用者空間已經有程式碼可以處理這個問題，透過檢測相關面板是否活躍（即 GPU 和麵板之間的多路複用器指向哪個方向），然後使用該背光裝置。然而，這裡的使用者空間非常假設只有一個面板。它只選擇兩個背光裝置中的一個，然後只使用那一個。

請注意，我所知道的所有使用者空間程式碼目前都硬編碼為假設單個面板。

在最近更改為不為一個面板（在單個 GPU 筆記型電腦上）註冊多個（例如，影片 + 本機）/sys/class/backlight 裝置之前，使用者空間會看到多個背光裝置都在控制同一個背光。

為了解決這個問題，使用者空間必須始終在 /sys/class/backlight 下選擇一個首選裝置，並忽略其他裝置。因此，為了支援多個面板上的亮度控制，使用者空間也需要更新。

目前計劃透過向 drm_connector 面板物件新增“顯示亮度”屬性，允許透過 KMS API 進行亮度控制。這解決了 /sys/class/backlight API 的許多問題，包括無法將 sysfs 背光裝置對映到特定聯結器。任何用於在具有多個面板的裝置上新增亮度支援的使用者空間更改都應該基於這種新的 KMS 屬性。

聯絡人：Hans de Goede

級別：高階

緩衝區齡或其他緩衝區損傷累積演算法

進行每緩衝區上傳的驅動程式需要緩衝區損傷處理（而不是像進行每平面或每 CRTC 上傳的驅動程式那樣的幀損傷），但目前沒有支援獲取緩衝區齡或任何其他損傷累積演算法。

因此，如果附加到平面的幀緩衝自上次翻頁以來發生更改，損傷輔助函式就會回退到完整的平面更新。驅動程式將 &drm_plane_state.ignore_damage_clips 設定為 true，以指示 drm_atomic_helper_damage_iter_init() 和 drm_atomic_helper_damage_iter_next() 輔助函式應忽略損傷裁剪。

這應該得到改進，以便在執行每緩衝區上傳的驅動程式上正確跟蹤損傷。

有關損傷跟蹤的更多資訊以及學習材料的參考，請參閱 損傷跟蹤屬性。

聯絡人：Javier Martinez Canillas <javierm@redhat.com>

級別：高階

從 drm_syncobj 查詢錯誤

drm_syncobj 容器可以由與驅動程式無關的程式碼用於發出提交完成訊號。

一個仍缺少的小功能是用於查詢二進位制和時間線 drm_syncobj 錯誤狀態的通用 DRM IOCTL。

這應該透過實現必要的核心介面並在使用者空間堆疊中新增支援來改進。

聯絡人：Christian König

級別：入門

DRM 之外

將 fbdev 驅動程式轉換為 DRM

有大量針對舊硬體的 fbdev 驅動程式。有些硬體已經過時，但有些仍然提供良好（足夠）的幀緩衝。仍然有用的驅動程式應該轉換為 DRM，然後從 fbdev 中移除。

非常簡單的 fbdev 驅動程式最好透過從新的 DRM 驅動程式開始進行轉換。簡單的 KMS 輔助函式和 SHMEM 應該能夠處理任何現有硬體。新驅動程式的回撥函式是從現有 fbdev 程式碼中填充的。

更復雜的 fbdev 驅動程式可以藉助 DRM fbconv 輔助函式 [4] 逐步重構為 DRM 驅動程式。這些輔助函式提供了 DRM 核心基礎設施和 fbdev 驅動程式介面之間的轉換層。在 fbconv 輔助函式之上建立新的 DRM 驅動程式，複製 fbdev 驅動程式，並將其連線到 DRM 程式碼。Thomas Zimmermann 的 fbconv 樹中提供了幾個 fbdev 驅動程式的示例 [4]，以及此過程的教程 [5]。結果是一個可以執行 X11 和 Weston 的原始 DRM 驅動程式。

聯絡人：Thomas Zimmermann <tzimmermann@suse.de>

級別：高階