最近在研究Linux下的顯卡驅動，先從圖形顯示系統着手學習，搬運翻譯了wiki詞條。
一、Overview
Direct Rendering Manager(DRM)是linux內核子系統，負責與顯卡交互。 DRM提供一組API，用戶空間程序可以使用該API將命令和數據發送到GPU並執行諸如配置顯示器的模式設置之類的操作。DRM最初是作為X server Direct Rendering基礎結構的內核空間組件開發的，但從那以后它被其他圖形系統(例如Wayland)所使用。用戶空間程序可以使用DRM API命令GPU執行硬件加速的3D渲染和視頻解碼以及GPU計算。
Linux內核已經有一個fbdev的API，用於管理圖形適配器的幀緩存區，但不能用於滿足基於3D加速的現代基於GPU的視頻硬件的需求。這些設備通常需要在自己的內存中設置和管理命令隊列，以將命令分派給GPU，並且還需要管理該內存中的緩沖區和可用空間。最初，用戶空間程序(例如X server)直接管理這些資源，但通常它們的行為就像它們是唯一可以訪問GPU的程序一樣。當兩個或多個程序試圖同時控制相同的硬件，並以自己的方式設置每個資源時，大多數情況下，它們都是災難性。
DRM的創建是為了允許多個程序同時使用視頻硬件資源。DRM獲得對GPU的獨占訪問權，並負責初始化和維護命令隊列、內存和任何其他資源。希望使用GPU的程序將請求發送到DRM，DRM充當仲裁程序，並注意規避可能的沖突。
多年來，DRM的范圍已得到擴展，以涵蓋以前由用戶空間程序處理的多重功能，例如framebuffer管理和模式設置，內存共享對象和內存同步。這些擴展中的某些被賦予了特定的名稱，例如圖形執行管理器（GEM）或內核模式設置(KMS)，並且當特別提及它們提供的功能時，該術語將占上風，但它們仍然屬於整個內核DRM子系統的一部分。
二、Software architecture
DRM駐留在內核空間中，因此用戶空間程序必須使用內核系統調用來請求其服務。但是DRM沒有定義自己的自定義調用。相反，它遵循Unix原則“一切皆文件”，使用/dev層次結構下的設備文件通過文件系統名稱空間公開GPU。DRM檢測到的每個GPU都稱為DRM設備，並創建了一個設備文件/dev/dri/cardX（X是一個序列號）與之連接，並使用ioctl調用與DRM進行通信。不同的ioctl對應於DRM API的不同功能。
創建了一個名為libdrm的庫，以方便用戶空間程序與DRM子系統的接口。該庫只是一個包裝器，它為DRM API的每個ioctl提供用C編寫的函數，以及常量、結構和其他輔助元素。使用libdrm不僅避免將內核接口直接暴露給應用程序，而且還提供了在程序之間重用和共享代碼的優點。
DRM由兩部分組成：通用“DRM core”和每種受支持的特定部分（“DRM Driver”）。DRM core提供了可以注冊不同DRM驅動程序的基本框架，還為用戶空間提供了具有通用的，獨立於硬件的，功能的最少ioctl集。另一方面，DRM Driver實現API的硬件相關部分，具體取決於它所支持的GPU類型，它應提供DRM核心未涵蓋的其余ioctl的實現。
DRM驅動也可以擴展API，提供特定GPU上可用的具有附加功能的附加ioctl。當特定的DRM驅動程序提供增強的API時，用戶空間libdrm也將通過一個額外的庫libdrm-driver擴展，這個擴展庫可以被用戶空間用來調用其他ioctl接口。
2.1 API
DRM Core將幾個接口導出到用戶空間應用程序，讓相應的libdrm包裝成函數后來使用。
DRM Driver通過ioctl和sysfs文件導出設備專用的接口，供用戶空間驅動程序和支持設備的應用程序使用。外部接口包括：內存映射，上下文管理，DMA操作，AGP管理，vblank控制，fence管理，內存管理和輸出管理。
2.2 DRM-Master 和 DRM-Auth
DRM API 中有幾個 ioctl 由於並發問題僅限於用戶空間單個進程使用。為了實現這種限制，將 DRM 設備分為 Master 和 Auth。上述的那些 ioctl 只能被 DRM-Master 的進程調用。打開了 /dev/dri/cardX 的進程的文件句柄會被標志為 master，特別是第一個調用該 SET_MASTER ioctl 的進程。如果不是 DRM-Master 的進程在使用這些限制 ioctl 的時候會返回錯誤。進程也可以通過 DROP_MASTER ioctl 放棄 Master 角色，來讓其他進程變成 Master。
X Server 或者其他的 Display Server 通常會是他們所管理的 DRM 設備的 DRM-Master 進程。當 DRM 設備啟動的時候，這些 Display Server 打開設備節點，獲取 DRM-Master 權限，直到關閉設備。
對於其他的用戶空間進程，還有一種辦法可以獲得 DRM 設備的這些受限權限，這就是 DRM-Auth。它是一種針對 DRM 設備的驗證方式，用來證明該進程已經獲得了 DRM-Master 對於他們去訪問受限 ioctls 的許可。
步驟：
l DRM Client 使用 GET_MAGIC ioctl 從 DRM 設備獲取一個 32bit 整型的 token。並通過任何方式（通常是 IPC）傳遞給 DRM-Master。
l DRM-Master 進程使用 AUTH-MAGIC ioctl 返回 token 給 DRM 設備。
l 設備將 DRM-Master 所給的 token 和 Auth 的進行對比。通過的話就賦予進程文件句柄特殊的權限。
2.3 GEM
Graphics Execution Manager（GEM）是一種內存管理方法。由於視頻存儲器的大小增加以及諸如OpenGL之類的圖形API的日益復雜性，從性能角度看，在每個上下文切換處重新初始化圖形卡狀態的策略過於低效。另外，現代linux桌面還需要一種最佳方式與合成管理器（compositing manager）共享屏幕外緩沖區。這些要求誕生開發了用於管理內核內部圖形緩沖區的新方法，圖形執行管理方法（GEM）是其中一種。
GEM為API提供了顯式的內存管理原語。通過GEM，用戶空間程序可以創建，處理和銷魂GPU視頻內存中的內存對象（Bo）。從用戶空間程序的角度看，這些被稱為“GEM對象”的對象是持久性的，不需要在程序每次重新獲得對GPU的控制時對重新加載它們。當用戶空間程序需要大量的視頻內存（以存儲framebuffer，紋理或者GPU所需的任何其他數據）時，它將使用GEM API請求分配給DRM驅動程序。DRM驅動程序會跟蹤已使用的視頻內存，如果有可用的空閑內存，則能夠滿足請求，將“句柄”返回給用戶空間，以在以后的操作中進一步引用分配的內存。GEM API還提供了一些操作，以填充緩沖區並在不再需要時釋放緩沖區。當用戶空間進程有意或由於終止而關閉了DRM設備文件描述符時，未釋放的GEM句柄中的內存將恢復。
GEM還允許使用同一DRM設備（因此使用相同的DRM驅動程序）的兩個或多個用戶空間進程共享GEM對象。GEM句柄時是某個進程唯一的局部32位整數，但在其他進程中可重復，因此不適合共享。所需要的是一個全局命名空間，GEM通過使用稱為GEM names的全局句柄來提供一個命名空間。GEM名稱是指使用相同的DRM驅動程序在同一個DRM設備中通過使用唯一的32位整數創建的一個GEM對象，並且僅是一個GEM對象。GEM提供了一個操作flink來從GEM句柄獲取GEM名稱。然后，該進程可以使用任何可用的IPC機制將該GEM名稱（32位整數）傳遞給一個進程。接收方進程可以通過GEM名稱來獲取原始GEM對象的本地GEM句柄。
不幸的是，使用GEM名稱共享緩沖區並不安全。一個惡意的第三方進程訪問同一DRM設備可以會試圖通過探查32位整數來猜測其他兩個進程共享的緩沖區的GEM名稱。一旦找到GEM名稱，就可以訪問和修改其內容，從而違反了緩沖區信息的機密性和完整性。后來通過在DRM中引入了DMA-BUF支持來克服此缺點，因為DMA-BUF將用戶空間中的緩沖區表示為文件描述符，可以安全的共享它們。
除了管理視頻內存空間外，任何視頻內存管理系統的另一個重要任務是處理GPU和CPU之間的內存同步。當前的存儲器架構非常復雜，並且通常涉及用於系統存儲器以及有時也用於視頻存儲器的各種級別的高速緩存。因此，視頻內存管理器還應處理緩存一致性，以確保CPU和GPU之間共享的數據一致。這意味着視頻內存管理內部結構通常高度依賴於GPU和存儲體系結構的硬件細節，因此取決於驅動程序。
GEM最初是由英特爾工程師開發的，旨在為其i915驅動程序提供視頻存儲管理器。英特爾GMA 9xx家族是具有統一內存架構（UMA）的集成GPU，其中GPU和CPU共享物理內存，並且沒有專用的VRAM。GEM定義了用於內存同步的“內存域”，盡管這些內存域與GPU無關，但它們在設計時特別考慮了UMA內存架構，這使其不適用與其他內存架構，例如具有單獨VRAM的內存架構。因此，其他的DRM驅動程序已決定向用戶空間程序公開GEM API，但在內部它們實現了更適合其特定硬件和內存體系結構的其他內存管理器。
GEM API還提供了用於控制執行流（命令緩沖區）的ioctl，但它們是Intel特定的，可與Intel i915和更高版本的GPU一起使用。除了特定於內存管理的ioctl，沒有DRM驅動程序試圖去實現GEM API的其他任何部分。
2.4 Translation Table Maps
Translation Table Maps（TTM）是在GEM之前開發的用於GPU的通用內存管理器名稱。它專門用於管理GPU可能訪問的不同類型的內存，包括專用的Video RAM（通常安裝在顯卡中）與可通過稱為Graphics Address Remapping Table（GART）的I/O內存管理單元訪問的系統內存。考慮到用戶空間圖形應用程序通常會處理大量視頻數據，TTM還應處理CPU無法直接尋址的Video RAM部分，並以最佳性能來實現。另一個重要的事情是保持所涉及的不同內存和緩存之間的一致性。
TTM的主要概念是“緩沖對象”，即在某些時刻GPU是可尋址的視頻內存。當用戶空間圖形應用程序想要訪問某個緩沖對象（通常是用內容填充它）時，TTM可能需要將其重新定位為CPU可以尋址的一種存儲器。當GPU需要訪問的緩沖區對象還不在GPU的地址空間中時，可能會發生進一步的重定位或GART映射操作。這些重定位操作中的每一個都必須處理任何相關的數據和緩存一致性問題。
TTM的另一個重要概念是圍欄（fences）。圍欄本質上是一種管理CPU和GPU之間並發性的機制。圍欄跟蹤GPU何時不再使用緩沖區對象，通常用於通知任何具有訪問權限的用戶空間進程。
TTM試圖以合適的方式管理所有類型的內存體系結構，包括有和沒有專用VRAM的體系結構，並在內存管理器中提供所有可想到的功能，以便與任何類型的硬件一起使用，這導致了過於復雜的情況。API遠遠超出所需的解決方案。一些DRM開發人員認為它不適用於任何特定的驅動程序，尤其是API。當GEM成為一種更簡單的內存管理器時，它的API優於TTM。但是一些驅動程序開發人員認為TTM所采用的方法更適合於具有專用Video RAM和IOMMU的分立顯卡，因此他們決定在內部使用TTM，同時將其緩沖區對象公開為GEM對象，從而支持GEM API。當前使用TTM作為內部內存管理器但提供GEM API的驅動程序實例包括AMD顯卡的radeon驅動程序和NVIDIA顯卡的nouveau驅動程序。
2.5 DMA Buffer Sharing and PRIME
DMA緩沖區共享API（通常縮寫為DMA-BUF）是一種Linux內核內部API，旨在提供一種通用機制來在多個設備之間共享DMA緩沖區，並可能由不同類型的設備驅動進行管理。例如，Vdieo4Linux設備和圖形適配器設備可以通過DMA-BUF共享 緩沖區，以實現前者產生並由后者消耗的視頻流數據的零復制。任何Linux設備驅動程序都可以將此API實現為導出器、用戶（消費者）或者二者兼而有之。
在DRM中首次利用此功能來實現PRIME(擎天柱，顯卡交火)，這是一種用於GPU卸載的的解決方案，它使用DMA-BUF在獨立顯卡和集成顯卡的DRM驅動程序之間共享生成的framebuffer。DMA-BUF的一項重要功能是為了將共享緩沖區作為文件描述符提供給用戶空間。為了開發PRIME，在DRM API中添加了兩個新的ioctl，一個將本地GEM句柄轉換為DMA-BUF文件描述符，另一個用於相反的操作。
后來這兩個新的ioctl被用作解決GEM緩沖區共享固有的不安全性的一種方法。與GEM名稱不同，無法猜測到文件描述符（它們不是全局命名空間），並且Unix操作系統提供了一種安全的方法來傳遞Unix域套接字，通過使用SCM_RIGHTS語義。一個想要與另一個進程共享GEM對象的進程可以將本地GEM句柄轉換為DMA-BUF文件描述符，然后將其傳遞給接收者，后者可以從接收的文件描述符中獲得自己的GEM句柄。DRI3使用這種方法在客戶端和X Server或者Wayland之間共享緩沖區。
2.6 Kernel Mode Setting
為了正常工作，顯卡或者圖形適配器必須設置一種模式（屏幕分辨率、顏色深度和刷新率的組合），該模式應在其自身和所連接的顯示屏所支持的值的范圍內。此操作稱為mode-setting。通常需要對圖形硬件進行原始訪問，寫入視頻卡某些寄存器的能力。在開始使用framebuffer之前，以及在應用程序或者用戶要求更改模式時，都必須執行模式設置操作。
在早期，希望使用圖形framebuffer的用戶空間程序還負責提供模式設置操作，因此它們需要在對視頻硬件進行特權訪問的情況下運行。在Unix類型的操作系統中，X Server是最突出的示例，其模式設置實現存在於每種特定類型的顯卡的DDX驅動程序中。這種方法（以后稱為用戶空間模式設置或UMS）帶來了幾個問題。這不僅打破了操作系統應在程序和硬件之間提供的隔離性，從而提高穩定性和安全性，而如果兩個或多個用戶空間程序嘗試在操作系統上進行模式設置，可能會使圖形硬件處於不一致的狀態。同時，為了避免這種沖突，實際上X Server成為了唯一執行模式設置操作的用戶空間程序。其余的用戶空間程序依靠X Server來設置適當的模式並處理涉及模式設置的任何其他操作。最初，模式設置僅在X Server啟動過程中執行，但是后來X Server可以在運行時進行設置。XFree86 3.1.2中引入了XFree-VidModeExtension擴展，以允許X-Client請求對X Server的modeline（分辨率）更改。VidModeExtension后來被更加通用的XRandR擴展取代。
然而，這不是在linux系統中進行模式設置的唯一代碼。在系統引導過程中，Linux內核必須為虛擬控制台設置最小文本模式（基於VESA BIOS擴展定義的標准模式）。Linux內核幀緩沖驅動程序還包含用於配置幀緩沖設備的模式代碼。為了避免模式設置沖突，XFree86 Server（以及后來的X.Org Server）在用戶從圖形環境切換到文本虛擬控制台時保存模式設置狀態，並在切回到X圖形環境時還原它。此過程在過渡中引發了閃爍現象，並且還可能失敗，從而導致輸出顯示損壞或無法使用。
用戶空間模式設置方法還引起了其他問題：
Ø 掛起/恢復過程必須依靠用戶空間工具來恢復以前的模式。由於模式集配置錯誤，這些程序之一的單個故障或崩潰可能會使系統無法正常顯示，因此無法使用。
Ø 當屏幕處於圖形模式時（例如運行X），內核也不可能顯示錯誤或調試信息，因為內核知道的唯一模式是VESA_BIOS標准文本模式。
Ø 更為緊迫的問題是繞過X Server的圖形應用程序的激增以及X的其他圖形棧替代方案的出現，從而進一步擴展了模式設置代碼在整個系統中的重復。
為了解決這些問題，將模式設置代碼移至內核中的單個位置，放到了現有的DRM模塊中。然后每個進程（包括X Server）都應該能夠命令內核執行模式設置操作，並且內核將確保並發操作不會導致不一致的狀態。添加到DRM模塊以執行這些模式設置操作的新內核API和代碼稱為Kernel Mode-Setting(KMS)。
Kernel Mode-Setting(KMS)有幾個好處。最直接是從內核（Linux控制台，fbdev）和用戶空間（X Server DDX驅動程序）中刪除重復的模式設置代碼。KMS還使編寫替代圖形系統變得更加容易，而這些圖形系統現在不需要實現自己的模式設置代碼。通過提供集中的模式管理，KMS解決了在控制台和X之間以及X的不同實例之間切換引起的閃屏問題。由於它在內核中可用，因此也可以在引導過程開始時使用它，從而避免了由於這些早期階段的模式更改而導致的閃爍。
Kernel Mode-Setting(KMS)是內核的一部分，這一事實使KMS可以使用僅在內核空間可用的資源（例如中斷）。例如，掛起/恢復過程后的模式恢復通過由內核本身進行管理，大大簡化了操作，並附帶地提高了安全性（不再需要具有root權限的用戶空間工具）。內核還可以輕松地熱拔插新的顯示設備，從而解決了一個長期存在的問題。模式設置也與內存管理密切相關，因為framebuffer基本上是內存緩沖區，因此強烈建議與圖形內存管理器緊密集成。這就是為什么將內核模式設置代碼合並到DRM中而不是作為一個單獨的子系統的主要原因。
為避免破壞DRM API的向后兼容性，內核模式設置作為某些DRM驅動程序的附件驅動程序功能提供。任何DRM驅動程序在向DRM內核注冊時都可以選擇提供DRIVER_MODESET標志，以指示它支持KMS API。那些實現內核模式設置的驅動程序通常被稱為KMS驅動程序，以將它們與傳統的（無KMS）DRM驅動。
KMS驅動已經被接受適配到了這種程度，某些缺少3D加速（或者硬件供應商不希望公開或者實現它）的驅動程序在沒有DRM其余API的情況下實現了KMS API。
2.7 KMS device model
KMS將輸出設備建模和管理為一系列抽象硬件模塊，這些模塊通常分布在顯示控制器的顯示輸出管道上。這些模塊是：
Ø CRTC：每個CRTC（來自CRT控制器）代表顯示控制器的掃描引擎，指向掃描緩沖區（framebuffer）。CRTC的目的是讀取當前在掃描緩沖區中的像素數據，並借助PLL電路從中生成視頻模式時序信號。可用的CRTC的數量決定了硬件可以同時處理多少個獨立的輸出設備，因此，要使用屏配置，每個顯示設備至少需要一個獨立的CRTC。兩個或更多個CRTC也可以工作在克隆模式下，它們從相同的framebuffer中掃描出來，將相同的圖像數據發送到多個輸出設備。
Ø Connector：連接器代表顯示控制器從掃描輸出中發送視頻信號到顯示的操作。通常，KMS連接器的概念對應於輸出設備（顯示器，筆記本電腦面板等）硬件中的物理連接器（VGA，DVI，FPD-Link，HDMI，DisplayPort，S-Video等），它是永久的，也可以是臨時的。與當前物理連接的輸出設備有關的信息（例如連接狀態，EDID數據，DPMS狀態或受支持的視頻模式）也存儲在連接器內。
Ø Encoder：顯示控制器必須對來自於CRTC視頻模式數據編碼為適合的符合預期的連接器的格式，以適配連接器。編碼器代表能夠執行這些編碼之一的硬件模塊。用於數字輸出的編碼示例為TMDS和LVDS；對於VGA和TV輸出等模擬輸出，通常使用特定的DAC模塊。一個連接器一次只能接受一個編碼器的信號，並且每種類型的連接器僅支持某些編碼。可能還會存在其他物理限制，即並非每個CRTC都連接到每個可用的編碼器，從而限制了CRTC-encoder-connector的可能組合。
Ø Plane：Plane不是硬件塊，而是一個包含向CRTC發送數據的緩存塊的內存對象。擁有framebuffer的Plane稱為主平面（primary plane），每個CRTC必須關聯一個平面，因為它是CRTC決定采用哪種視頻模式的根據—顯示分辨率（寬度和高度），像素大小，像素格式，刷新率等。如果顯示控制器支持硬件光標覆蓋，則CRTC可能還與光標平面相關聯；如果顯示控制器能夠從其他硬件覆蓋中掃描，並“即使”合成或混合發送到輸出設備的最終圖像，則CRTC可能與之關聯。
2.8 Atomic Display
近年來，人們一直在努力使與KMS API有關的某些常規操作具有原子性，尤其是與模式設置和頁面翻轉操作有關。這種增強的KMS API就是所謂的“原子顯示”（以前稱為“原子模式設置”和“原子或原子頁面翻轉”）。
原子模式設置的目的是通過避免可能導致視頻狀態不一致或無效的中間步驟，確保在具有多個限制的復雜配置中正確更改模式；在必須撤消失敗的模式設置過程（“回滾”）時，它還避免了危險的視頻狀態。原子模式設置通過提供模式測試功能，可以事先知道某些特定的模式配置是否合適。當測試原子模式並確認其有效性時，可以通過單個不可分割的（原子）提交操作來應用它。測試和提交操作均由具有不同標志的同一新ioctl提供。
另一方面，原子頁面翻轉允許在同一輸出上更新多個平面（例如主平面，光標平面以及可能的某些疊加或輔助平面），這些平面均在同一VBLANK間隔內同步，從而確保正確的顯示而不會撕裂。這項要求特別適用於移動和嵌入式顯示控制器，它們傾向於使用多個平面/疊層以節省功耗。
新的原子API是在舊的KMS API的基礎上構建的。 它使用相同的模型和對象（CRTC，Encoder，Connector，Plane等），但是可以修改的對象屬性越來越多。原子過程基於更改相關屬性以構建我們要測試或提交的狀態。 我們要修改的屬性取決於我們是否要進行模式設置（主要是CRTC，編碼器和連接器屬性）或頁面翻轉（通常是平面屬性）。這兩種情況的ioctl相同，不同之處在於每次傳遞的屬性列表。
2.9 Render nodes
在原始DRM API中，DRM設備“/dev/dri/cardX”用於特權（模式設置，其他顯示控件）和非特權（渲染，GPGPU計算）操作。 出於安全原因，打開關聯的DRM設備文件需要“等同於root特權”的特殊特權。這導致了一種體系結構，其中只有一些可靠的用戶空間程序（X服務器，圖形合成器等）可以完全訪問DRM API，包括特權部分（如模式集API）。 想要渲染或進行GPGPU計算的其余用戶空間應用程序應由DRM設備的所有者（“DRM主設備”）通過使用特殊的身份驗證界面來授予。然后，經過身份驗證的應用程序可以使用DRM API的受限版本來呈現或進行計算，而無需特權操作。這種設計施加了嚴格的約束：必須始終有運行中的圖形服務器（X服務器，Wayland合成器，...）充當DRM設備的DRM主設備，以便可以授予其他用戶空間程序使用DRM設備的權限，即使在不涉及任何圖形顯示（如GPGPU計算）的情況下。
“渲染節點（Render nodes）”概念試圖通過將DRM用戶空間API分成兩個接口（一個特權和一個非特權）並為每個接口使用單獨的設備文件（或“節點”）來解決這些情況。對於找到的每個GPU，其對應的DRM驅動程序（如果它支持渲染節點功能）除了主節點/dev /dri/cardX之外，還會創建一個設備文件/dev/dri/renderDX，稱為渲染節點。使用直接渲染模型的客戶端和想要利用GPU的計算功能的應用程序可以通過簡單地打開任何現有的渲染節點並使用DRM API支持的有限子集來分派GPU操作，而無需其他特權即可做到這一點--前提是它們具有打開設備文件的文件系統權限。 顯示服務器，合成器和任何其他請求模式API或任何其他特權操作的程序，都必須打開授予對完整DRM API的訪問權限的標准主節點，並像往常一樣使用它。渲染節點顯式禁止GEM flink操作，以防止使用不安全的GEM全局名稱共享緩沖區。 只能通過使用PRIME（DMA-BUF）文件描述符的方式，與包括圖形服務器在內的另一個客戶端共享緩沖區。
三、 Hardware support
如上圖所示，DRM將由用戶模式圖形設備程序使用，例如Mesa 3D。用戶空間程序使用Linux系統調用訪問DRM，DRM通過自身的系統調用來響應Linux的系統調用。
四、 Development
Direct Rendering Manager是在Linux內核中開發的，其源代碼位於Linux源代碼的/ drivers/gpu/drm目錄中。子系統維護者是Dave Airlie，其他維護者則負責特定的驅動程序。 與Linux內核開發一樣，DRM子維護者和貢獻者將具有新功能和錯誤修復的補丁程序發送給主要DRM維護者，后者將它們集成到自己的Linux存儲庫中。DRM維護者依次將所有這些修補程序提交給Linus Torvalds，這些修補程序隨時准備發布到Linux新版本中。 作為整個內核的頂級維護者，Torvalds保留了有關補丁是否適合包含在內核中的最后決定。
由於歷史原因，libdrm庫的源代碼保留在Mesa項目之下。