Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Direct Rendering Manager
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
{{Short description|Subsystem of the Linux kernel}} {{Distinguish|digital rights management}} {{Infobox software | name = | title = | logo = <!-- [[File: ]] --> | logo caption = | screenshot = <!-- [[File: ]] --> | caption = | collapsible = | author = [[kernel.org]] & [[freedesktop.org]] | developer = [[kernel.org]] & [[freedesktop.org]] | released = <!-- {{Start date|YYYY|MM|DD|df=yes/no}} --> | discontinued = | latest release version = | latest release date = <!-- {{Start date and age|YYYY|MM|DD|df=yes/no}} --> | latest preview version = | latest preview date = <!-- {{Start date and age|YYYY|MM|DD|df=yes/no}} --> | programming language = [[C (programming language)|C]] | operating system = | platform = | size = | language = | genre = {{unbulleted list|[[Device driver]]|[[Loadable kernel module]]}} | license = {{unbulleted list|[[MIT License]]{{citation needed|date=July 2014}}|[[GNU General Public License|GPL]]{{citation needed|date=July 2014}}}} | website = {{URL|http://dri.freedesktop.org/wiki/DRM}} }} The '''Direct Rendering Manager''' ('''DRM''') is a subsystem of the [[Linux kernel]] responsible for interfacing with [[Graphics processing unit|GPUs]] of modern [[video cards]]. DRM exposes an [[Application programming interface|API]] that [[user-space]] programs can use to send commands and data to the GPU and perform operations such as configuring the [[mode setting]] of the display. DRM was first developed as the [[kernel-space]] component of the [[X.Org Server|X Server]] [[Direct Rendering Infrastructure]],{{r|DRM readme}} but since then it has been used by other graphic stack alternatives such as [[Wayland (display server protocol)|Wayland]] and standalone applications and libraries such as [[Simple DirectMedia Layer | SDL2]] and [[Kodi (software) | Kodi]]. User-space programs can use the DRM API to command the GPU to do [[hardware acceleration|hardware-accelerated]] [[3D rendering]] and [[video decoding]], as well as [[General-purpose computing on graphics processing units|GPGPU computing]]. == Overview == The [[Linux kernel]] already had an [[Application programming interface|API]] called [[Linux framebuffer|fbdev]], used to manage the [[framebuffer]] of a [[graphics adapter]],{{r|fb doc}} but it couldn't be used to handle the needs of modern 3D-accelerated [[GPU]]-based video hardware. These devices usually require setting and managing a command queue in [[Video RAM|their own memory]] to dispatch commands to the GPU and also require management of buffers and free space within that memory.{{r|White}} Initially, user-space programs (such as the [[X Window System|X Server]]) directly managed these resources, but they usually acted as if they were the only ones with access to them. When two or more programs tried to control the same hardware at the same time, and set its resources each one in its own way, most times they ended catastrophically.{{r|White}} {{multiple image | footer = DRM allows multiple programs concurrent access to the 3D video card, avoiding collisions. | image1 = Access to video card without DRM.svg | alt1 = Access to video card without DRM | caption1 = Without DRM | image2 = Access to video card with DRM.svg | alt2 = Access to video card with DRM | caption2 = With DRM }} The Direct Rendering Manager was created to allow multiple programs to use video hardware resources cooperatively.{{r|Faith 1999}} The DRM gets exclusive access to the GPU and is responsible for initializing and maintaining the command queue, memory, and any other hardware resource. Programs wishing to use the GPU send requests to DRM, which acts as an arbitrator and takes care to avoid possible conflicts. The scope of DRM has been expanded over the years to cover more functionality previously handled by user-space programs, such as framebuffer managing and [[mode setting]], memory-sharing objects and memory synchronization.{{r|Corbet 2007}}{{r|Packard Anholt 2008}} Some of these expansions were given specific names, such as [[Graphics Execution Manager]] (GEM) or [[kernel mode-setting]] (KMS), and the terminology prevails when the functionality they provide is specifically alluded. But they are really parts of the whole kernel DRM subsystem. The trend to include two GPUs in a computer—a discrete GPU and an integrated one—led to new problems such as [[GPU switching]] that also needed to be solved at the DRM layer. In order to match the [[Nvidia Optimus]] technology, DRM was provided with GPU offloading abilities, called PRIME.{{r|Airlie 2010}} == Software architecture == [[File:High level Overview of DRM.svg|thumb|A process using the Direct Rendering Manager of the Linux Kernel to access a 3D accelerated graphics card]] The Direct Rendering Manager resides in [[kernel space]], so user-space programs must use kernel [[system call]]s to request its services. However, DRM doesn't define its own customized system calls. Instead, it follows the [[Unix]] principle of "[[everything is a file]]" to expose the [[GPU]]s through the filesystem name space, using [[device file]]s under the <code>/dev</code> hierarchy. Each GPU detected by DRM is referred to as a ''DRM device'', and a device file <code>/dev/dri/card''X''</code> (where ''X'' is a sequential number) is created to interface with it.{{r|Kitching 2012}}{{r|Herrmann 2013 DRM split}} User-space programs that want to talk to the GPU must [[open (system call)|open]] this file and use [[ioctl]] calls to communicate with DRM. Different ioctls correspond to different functions of the DRM [[Application programming interface|API]]. A [[Library (computing)|library]] called ''libdrm'' was created to facilitate the interface of user-space programs with the DRM subsystem. This library is merely a [[Wrapper library|wrapper]] that provides a [[Subroutine|function]] written in [[C (programming language)|C]] for every ioctl of the DRM API, as well as constants, structures and other helper elements.{{r|libdrm README}} The use of libdrm not only avoids exposing the kernel interface directly to applications, but presents the usual advantages of [[Code reuse|reusing]] and sharing code between programs. [[File:DRM architecture.svg|thumb|Direct Rendering Manager architecture details: DRM core and DRM driver (including GEM and KMS) interfaced by libdrm]] DRM consists of two parts: a generic "DRM core" and a specific one ("DRM driver") for each type of supported hardware.{{r|Airlie redesign}} DRM core provides the basic framework where different DRM drivers can register and also provides to user space a minimal set of ioctls with common, hardware-independent functionality.{{r|Kitching 2012}} A DRM driver, on the other hand, implements the hardware-dependent part of the API, specific to the type of GPU it supports; it should provide the implementation of the remaining ioctls not covered by DRM core, but it may also extend the API, offering additional ioctls with extra functionality only available on such hardware.{{r|Kitching 2012}} When a specific DRM driver provides an enhanced API, user-space libdrm is also extended by an extra library libdrm-''driver'' that can be used by user space to interface with the additional ioctls. === API === The DRM core exports several interfaces to user-space applications, generally intended to be used through corresponding <code>libdrm</code> wrapper functions. In addition, drivers export device-specific interfaces for use by user-space drivers and device-aware applications through [[ioctl]]s and [[sysfs]] files. External interfaces include: memory mapping, context management, [[Direct memory access|DMA]] operations, [[Accelerated Graphics Port|AGP]] management, [[Vertical blanking interval|vblank]] control, fence management, memory management, and output management. ==== DRM-Master and DRM-Auth ==== There are several operations (ioctls) in the DRM API that either for security purposes or for concurrency issues must be restricted to be used by a single user-space process per device.{{r|Kitching 2012}} To implement this restriction, DRM limits such ioctls to be only invoked by the process considered the "master" of a DRM device, usually called ''DRM-Master''. Only one of all processes that have the device node <code>/dev/dri/card''X''</code> opened will have its [[file handle]] marked as master, specifically the first calling the {{mono|SET_MASTER}} ioctl. Any attempt to use one of these restricted ioctls without being the DRM-Master will return an error. A process can also give up its master role—and let another process acquire it—by calling the {{mono|DROP_MASTER}} ioctl. The [[X Window System|X Server]]—or any other [[display server]]—is commonly the process that acquires the DRM-Master status in every DRM device it manages, usually when it opens the corresponding device node during its startup, and keeps these privileges for the entire graphical session until it finishes or dies. For the remaining user-space processes there is another way to gain the privilege to invoke some restricted operations on the DRM device called ''DRM-Auth''. It is basically a method of authentication against the DRM device, in order to prove to it that the process has the DRM-Master's approval to get such privileges. The procedure consists of:{{r|Peres Ravier 2013|p=13}} * The client gets a unique token—a 32-bit integer—from the DRM device using the {{mono|GET_MAGIC}} ioctl and passes it to the DRM-Master process by whatever means (normally some sort of [[Inter-process communication|IPC]]; for example, in [[DRI2]] there is a {{mono|DRI2Authenticate}} request that any X client can send to the X Server.{{r|DRI2 spec}}) * The DRM-Master process, in turn, sends back the token to the DRM device by invoking the {{mono|AUTH_MAGIC}} ioctl. * The device grants special rights to the process file handle whose auth token matches the received token from the DRM-Master. === Graphics Execution Manager === Due to the increasing size of [[video memory]] and the growing complexity of graphics APIs such as [[OpenGL]], the strategy of reinitializing the graphics card state at each [[context switch]] was too expensive, performance-wise. Also, modern [[Linux desktop]]s needed an optimal way to share off-screen buffers with the [[compositing manager]]. These requirements led to the development of new methods to manage graphics [[Data buffer|buffers]] inside the kernel. The ''Graphics Execution Manager'' (GEM) emerged as one of these methods.{{r|Packard Anholt 2008}} GEM provides an API with explicit [[memory management]] primitives.{{r|Packard Anholt 2008}} Through GEM, a user-space program can create, handle and destroy memory objects living in the GPU video memory. These objects, called "GEM objects",{{r|drmbook-mm}} are persistent from the user-space program's perspective and don't need to be reloaded every time the program regains control of the GPU. When a user-space program needs a chunk of video memory (to store a [[framebuffer]], [[Texture mapping|texture]] or any other data required by the GPU{{r|Vetter 2012}}), it requests the allocation to the DRM driver using the GEM API. The DRM driver keeps track of the used video memory and is able to comply with the request if there is free memory available, returning a "handle" to user space to further refer the allocated memory in coming operations.{{r|Packard Anholt 2008}}{{r|drmbook-mm}} GEM API also provides operations to populate the buffer and to release it when it is not needed anymore. Memory from unreleased GEM handles gets recovered when the user-space process closes the DRM device [[file descriptor]]—intentionally or because it terminates.{{r|Vetter 2011}} GEM also allows two or more user-space [[Process (computing)|processes]] using the same DRM device (hence the same DRM driver) to share a GEM object.{{r|Vetter 2011}} GEM handles are local 32-bit integers unique to a process but repeatable in other processes, therefore not suitable for sharing. What is needed is a global namespace, and GEM provides one through the use of global handles called ''GEM names''. A GEM name refers to one, and only one, GEM object created within the same DRM device by the same DRM driver, by using a unique 32-bit [[Integer (computer science)|integer]]. GEM provides an operation ''flink'' to obtain a GEM name from a GEM handle.{{r|Vetter 2011}}{{r|Peres Ravier 2013|p=16}} The process can then pass this GEM name (32-bit integer) to another process using any [[Inter-process communication|IPC]] mechanism available.{{r|Peres Ravier 2013|p=15}} The GEM name can be used by the recipient process to obtain a local GEM handle pointing to the original GEM object. Unfortunately, the use of GEM names to share buffers is not secure.{{r|Peres Ravier 2013|p=16}}{{r|Packard 2012}}{{r|Herrmann 2013 XDC}} A malicious third-party process accessing the same DRM device could try to guess the GEM name of a buffer shared by two other processes, simply by probing 32-bit integers.{{r|Kerrisk 2012}}{{r|Herrmann 2013 XDC}} Once a GEM name is found, its contents can be accessed and modified, violating the [[CIA triad|confidentiality and integrity]] of the information of the buffer. This drawback was overcome later by the introduction of [[DMA-BUF]] support into DRM, as DMA-BUF represents buffers in userspace as file descriptors, which [[File descriptor#File descriptors as capabilities|may be shared securely]]. Another important task for any video-memory management system besides managing the video-memory space is handling the memory synchronization between the GPU and the CPU. Current [[memory architecture]]s are very complex and usually involve various levels of [[CPU cache|caches]] for the system memory and sometimes for the video memory too. Therefore, video-memory managers should also handle the [[cache coherence]] to ensure the data shared between CPU and GPU is consistent.{{r|Packard 2008 GEM}} This means that often video-memory management internals are highly dependent on hardware details of the GPU and memory architecture, and thus driver-specific.{{r|drm-mem manpage}} GEM was initially developed by [[Intel]] engineers to provide a video-memory manager for its i915 driver.{{r|Packard 2008 GEM}} The [[Intel GMA#Intel GPU based|Intel GMA 9xx]] family are [[GPU#Integrated graphics|integrated GPUs]] with a Uniform Memory Architecture (UMA), where the GPU and CPU share the physical memory, and there is not a dedicated VRAM.{{r|Intel UMA}} GEM defines "memory domains" for memory synchronization, and while these memory domains are GPU-independent,{{r|Packard Anholt 2008}} they are specifically designed with an UMA memory architecture in mind, making them less suitable for other memory architectures like those with a separate VRAM. For this reason, other DRM drivers have decided to expose to user-space programs the GEM API, but internally they implemented a different memory manager better suited for their particular hardware and memory architecture.{{r|Larabel 2008 gem-ttm}} The GEM API also provides ioctls for control of the execution flow (command buffers), but they are Intel-specific, to be used with Intel i915 and later GPUs.{{r|Packard Anholt 2008}} No other DRM driver has attempted to implement any part of the GEM API beyond the memory-management specific ioctls. ==== Translation Table Maps ==== ''Translation Table Maps'' (TTM) is the name of the generic memory manager for GPUs that was developed before GEM.{{r|Corbet 2007}}{{r|drmbook-mm}} It was specifically designed to manage the different types of memory that a GPU might access, including dedicated [[Video RAM]] (commonly installed in the video card) and [[main memory|system memory]] accessible through an [[Input–output memory management unit|I/O memory management unit]] called the [[Graphics Address Remapping Table]] (GART).{{r|Corbet 2007}} TTM should also handle the portions of the video RAM that are not directly addressable by the CPU and do it with the best possible performance, considering that user-space graphics applications typically work with large amounts of video data. Another important matter was to maintain the consistency between the different memories and caches involved. The main concept of TTM are the "buffer objects", regions of video memory that at some point must be addressable by the GPU.{{r|Corbet 2007}} When a user-space graphics application wants access to a certain buffer object (usually to fill it with content), TTM may require relocating it to a type of memory addressable by the CPU. Further relocations—or GART mapping operations—could happen when the GPU needs access to a buffer object but it isn't in the GPU's address space yet. Each of these relocation operations must handle any related data and cache-coherency issues.{{r|Corbet 2007}} Another important TTM concept is ''[[Memory barrier|fences]]''. Fences are essentially a mechanism to manage concurrency between the CPU and the GPU.{{r|Corbet 2008}} A fence tracks when a buffer object is no longer used by the GPU, generally to notify any user-space process with access to it.{{r|Corbet 2007}} The fact that TTM tried to manage all kind of memory architectures, including those with and without a dedicated VRAM, in a suitable way, and to provide every conceivable feature in a memory manager for use with any type of hardware, led to an overly complex solution with an API far larger than needed.{{r|Corbet 2008}}{{r|drmbook-mm}} Some DRM developers thought that it wouldn't fit well with any specific driver, especially the API. When GEM emerged as a simpler memory manager, its API was preferred over the TTM one. But some driver developers considered that the approach taken by TTM was more suitable for discrete video cards with dedicated video memory and IOMMUs, so they decided to use TTM internally, while exposing their buffer objects as GEM objects and thus supporting the GEM API.{{r|Larabel 2008 gem-ttm}} Examples of current drivers using TTM as an internal memory manager but providing a GEM API are the radeon driver for AMD video cards and the [[nouveau (software)|nouveau]] driver for NVIDIA video cards. ==== {{Anchor|PRIME}} DMA Buffer Sharing and PRIME ==== The ''DMA Buffer Sharing API'' (often abbreviated as DMA-BUF) is a [[Linux kernel]] internal [[Application programming interface|API]] designed to provide a generic mechanism to share [[Direct memory access|DMA]] buffers across multiple devices, possibly managed by different types of device drivers.{{r|Corbet 2012 dmabuf}}{{r|Clark Semwal 2012}} For example, a [[Video4Linux]] device and a graphics adapter device could share buffers through DMA-BUF to achieve [[zero-copy]] of the data of a video stream produced by the first and consumed by the latter. Any Linux [[device driver]] can implement this API as exporter, as user (consumer) or both. This feature was exploited for the first time in DRM to implement PRIME, a solution for [[GPU offloading]] that uses DMA-BUF to share the resulting framebuffers between the DRM drivers of the discrete and the integrated GPU.{{r|Peres 2014|p=13}} An important feature of DMA-BUF is that a shared buffer is presented to user space as a [[file descriptor]].{{r|drmbook-mm}}{{r|Peres Ravier 2013|p=17}} For the development of PRIME two new ioctls were added to the DRM API, one to convert a local GEM handle to a DMA-BUF file descriptor and another for the exact opposite operation. These two new ioctls were later reused as a way to fix the inherent unsafety of GEM buffer sharing.{{r|Peres Ravier 2013|p=17}} Unlike GEM names, file descriptors can not be guessed (they are not a global namespace), and Unix operating systems provide a safe way to pass them through a [[Unix domain socket]] using the SCM_RIGHTS semantics.{{r|drmbook-mm}}{{r|Pinchart 2013|p=11}} A process that wants to share a GEM object with another process can convert its local GEM handle to a DMA-BUF file descriptor and pass it to the recipient, which in turn can get its own GEM handle from the received file descriptor.{{r|Peres Ravier 2013|p=16}} This method is used by [[Direct Rendering Infrastructure|DRI3]] to share buffers between the client and the X Server{{r|Edge 2013}} and also by [[Wayland (display server protocol)|Wayland]]. === {{Anchor|Kernel mode setting|KMS driver}} Kernel Mode Setting === [[File:Linux kernel and daemons with exclusive access.svg|thumb|There must be a "DRM master" in user-space, this program has exclusive access to KMS.]] In order to work properly, a video card or graphics adapter must set a ''[[Framebuffer#Display modes|mode]]''—a combination of [[screen resolution]], [[color depth]] and [[refresh rate]]—that is within the range of values supported by itself and the attached [[Computer monitor|display screen]]. This operation is called [[mode-setting]],{{r|Kernelnewbies linux 2.6.29}} and it usually requires raw access to the graphics hardware—i.e. the ability to write to certain registers of the video card [[display controller]].{{r|OSDev VGA}}{{r|Rathmann 2008}} A mode-setting operation must be performed before starting to use the [[framebuffer]], and also when the mode is required to change by an application or the user. In the early days, [[User_space_and_kernel_space|user-space]] programs that wanted to use the graphical framebuffer were also responsible for providing the mode-setting operations.{{r|White}} Thus, they needed to run with privileged access to the video hardware. In Unix-type operating systems, the [[X Window System|X Server]] was the most prominent example. Its mode-setting implementation lived in the [[Device Dependent X|DDX driver]] for each specific type of video card.{{r|Paalanen 2014}} This approach, later referred to as ''User space Mode-Setting'' or UMS,{{r|kms manpage}}{{r|Corbet 2010}} poses several issues.{{r|X wiki modesetting}}{{r|Kernelnewbies linux 2.6.29}} It not only breaks the isolation that operating systems should provide between programs and hardware, raising both stability and security concerns, but also could leave the graphics hardware in an inconsistent state if two or more user space programs try to do the mode-setting at the same time. To avoid these conflicts, the X Server became in practice the only user space program that performed mode-setting operations; the remainder user space programs relied on the X Server to set the appropriate mode and to handle any other operation involving mode-setting. Initially the mode-setting was performed exclusively during the X Server startup process, but later the X Server gained the ability to do it while running.{{r|Corbet 2007 LCA}} The XFree86-VidModeExtension extension was introduced in [[XFree86]] 3.1.2 to let any X client request [[XFree86 Modeline|modeline]] (resolution) changes to the X Server.{{r|XF86vidmode man}}{{r|X11R6.1 relnotes}} VidMode extension was later superseded by the more generic [[XRandR]] extension. However, this was not the only code doing mode-setting in a [[Linux]] system. During the system booting process, the Linux kernel must set a minimal [[text mode]] for the [[Linux console|virtual console]] (based on the standard modes defined by [[VESA BIOS]] extensions).{{r|Corbet 2004}} Also the [[Linux framebuffer|Linux kernel framebuffer driver]] contained mode-setting code to configure framebuffer devices.{{r|fb doc}} To avoid mode-setting conflicts, the [[XFree86|XFree86 Server]]—and later the [[X.Org Server]]—handled the case when the user switched from the graphical environment to a text [[virtual console]] by saving its mode-setting state, and restoring it when the user switched back to X.{{r|Fedora KMS}} This process caused an annoying flicker in the transition, and also can fail, leading to a corrupted or unusable output display.{{r|Barnes modesetting}} The user space mode setting approach also caused other issues:{{r|DRI Wiki modesetting}}{{r|Barnes modesetting}} * The [[sleep mode|suspend/resume process]] has to rely on user space tools to restore the previous mode. One single failure or crash of one of these programs could leave the system without a working display due to a modeset misconfiguration, and therefore unusable. * It was also impossible for the kernel to show error or debug messages when the screen was in a graphics mode—for example when X was running—since the only modes the kernel knew about were the VESA BIOS standard text modes. * A more pressing issue was the proliferation of graphical applications bypassing the X Server and the emergence of other graphics stack alternatives to X, extending the duplication of mode-setting code across the system even further. To address these problems, the mode-setting code was moved to a single place inside the kernel, specifically to the existing DRM module.{{r|X wiki modesetting}}{{r|Corbet 2007 LCA}}{{r|Packard 2007}}{{r|Barnes modesetting}}{{r|DRI Wiki modesetting}} Then, every process—including the X Server—should be able to command the kernel to perform mode-setting operations, and the kernel would ensure that concurrent operations don't result in an inconsistent state. The new kernel API and code added to the DRM module to perform these mode-setting operations was called ''Kernel Mode-Setting'' (KMS).{{r|Kernelnewbies linux 2.6.29}} Kernel Mode-Setting provides several benefits. The most immediate is of course the removal of duplicate mode-setting code, from both the kernel (Linux console, fbdev) and user space (X Server DDX drivers). KMS also makes it easier to write alternative graphics systems, which now don't need to implement their own mode-setting code.{{r|Barnes modesetting}}{{r|DRI Wiki modesetting}} By providing centralized mode management, KMS solves the flickering issues while changing between console and X, and also between different instances of X (fast user switching).{{r|Fedora KMS}}{{r|Packard 2007}} Since it is available in the kernel, it can also be used at the beginning of the boot process, saving flickering due to mode changes in these early stages. The fact that KMS is part of the kernel allows it to use resources only available at kernel space such as [[Hardware interrupt|interrupts]].{{r|Packard 2009}} For example, the mode recovery after a suspend/resume process simplifies a lot by being managed by the kernel itself, and incidentally improves security (no more user space tools requiring root permissions). The kernel also allows the [[hotplug]] of new display devices easily, solving a longstanding problem.{{r|Packard 2009}} Mode-setting is also closely related to memory management—since framebuffers are basically memory buffers—so a tight integration with the graphics memory manager is highly recommended. That's the main reason why the kernel mode-setting code was incorporated into DRM and not as a separate subsystem.{{r|Packard 2007}} To avoid breaking backwards compatibility of the DRM API, Kernel Mode-Setting is provided as an additional ''driver feature'' of certain DRM drivers.{{r|drmbook-init}} Any DRM driver can choose to provide the {{mono|DRIVER_MODESET}} flag when it registers with the DRM core to indicate that supports the KMS API.{{r|Kitching 2012}} Those drivers that implement Kernel Mode-Setting are often called ''KMS drivers'' as a way to differentiate them from the legacy—without KMS—DRM drivers. KMS has been adopted to such an extent that certain drivers which lack 3D acceleration (or for which the hardware vendor doesn't want to expose or implement it) nevertheless implement the KMS API without the rest of the DRM API, allowing display servers (like [[Wayland (protocol)|Wayland]]) to run with ease.<ref>{{Cite web |date=2023-01-31 |title=q3k (@q3k@hackerspace.pl) |url=https://social.hackerspace.pl/@q3k/109783347119397449 |access-date=2023-02-13 |website=Warsaw Hackerspace Social Club |language=en |quote=DRM/KMS driver fully working now, although still without DMA. Oh, and it's written in Rust, although it's mostly just full of raw unsafe blocks.}}</ref><ref>{{Cite web |date=2023-01-31 |title=q3k (@q3k@hackerspace.pl) |url=https://social.hackerspace.pl/@q3k/109785149255867298 |access-date=2023-02-13 |website=Warsaw Hackerspace Social Club |language=en |quote=Cool thing is, since we have a 'normal' DRM/KMS driver (and help from @emersion@hackerspace.pl) we can just do things like... run Wayland! Weston on an iPod Nano 5G.}}</ref> ==== KMS device model ==== KMS models and manages the output devices as a series of abstract hardware blocks commonly found on the display output pipeline of a [[display controller]]. These blocks are:{{r|drmbook-kms}} * '''CRTCs''': each CRTC (from [[Cathode-ray tube|CRT]] Controller{{r|X wiki videocards}}{{r|Paalanen 2014}}) represents a scanout engine of the display controller, pointing to a ''scanout buffer'' ([[framebuffer]]).{{r|drmbook-kms}} The purpose of a CRTC is to read the pixel data currently in the scanout buffer and generate from it the [[Video signal|video mode timing signal]] with the help of a [[Phase-locked loop|PLL circuit]].{{r|Deucher 2010}} The number of CRTCs available determines how many independent output devices the hardware can handle at the same time, so in order to use ''[[Multi-monitor|multi-head]]'' configurations at least one CRTC per display device is required.{{r|drmbook-kms}} Two—or more—CRTCs can also work in ''clone mode'' if they scan out from the same framebuffer to send the same image to several output devices.{{r|Deucher 2010}}{{r|X wiki videocards}} * '''Connectors''': a connector represents where the display controller sends the video signal from a scanout operation to be displayed. Usually, the KMS concept of a connector corresponds to a physical connector ([[VGA connector|VGA]], [[Digital Visual Interface|DVI]], [[FPD-Link]], [[HDMI]], [[DisplayPort]], [[S-Video]], ...) in the hardware where an output device ([[Computer monitor|monitor]], [[laptop]] panel, ...) is permanently or can temporarily be attached. Information related to the current physically attached output device—such as connection status, [[Extended Display Identification Data|EDID]] data, [[VESA Display Power Management Signaling|DPMS]] status or supported video modes—is also stored within the connector.{{r|drmbook-kms}} * '''Encoders''': the display controller must encode the video mode timing signal from the CRTC using a format suitable for the intended connector.{{r|drmbook-kms}} An encoder represents the hardware block able to do one of these encodings. Examples of encodings—for digital outputs—are [[Transition-minimized differential signaling|TMDS]] and [[Low-voltage differential signaling|LVDS]]; for analog outputs such as [[Video Graphics Array|VGA]] and TV out, specific [[Digital-to-analog converter|DAC]] blocks are generally used. A connector can only receive the signal from one encoder at a time,{{r|drmbook-kms}} and each type of connector only supports some encodings. There also might be additional physical restrictions by which not every CRTC is connected to every available encoder, limiting the possible combinations of CRTC-encoder-connector. * '''Planes''': a plane is not a hardware block but a memory object containing a buffer from which a scanout engine (a CRTC) is fed. The plane that holds the [[framebuffer]] is called the ''primary plane'', and each CRTC must have one associated,{{r|drmbook-kms}} since it is the source for the CRTC to determine the video mode—display resolution (width and height), pixel size, pixel format, refresh rate, etc. A CRTC might have also ''cursor planes'' associated to it if the display controller supports hardware cursor overlays, or ''secondary planes'' if it's able to scan out from additional [[hardware overlay]]s and compose or blend "on the fly" the final image sent to the output device.{{r|Paalanen 2014}} ==== {{Anchor|Atomic mode setting|nuclear pageflip}}Atomic Display ==== In recent years there has been an ongoing effort to bring [[Atomicity (programming)|atomicity]] to some regular operations pertaining the KMS API, specifically to the [[mode setting]] and [[page flipping]] operations.{{r|Paalanen 2014}}{{r|Vetter 2015 LWN p1}} This enhanced KMS API is what is called ''Atomic Display'' (formerly known as ''atomic mode-setting'' and ''atomic'' or ''nuclear pageflip''). The purpose of the ''atomic mode-setting'' is to ensure a correct change of mode in complex configurations with multiple restrictions, by avoiding intermediate steps which could lead to an inconsistent or invalid video state;{{r|Vetter 2015 LWN p1}} it also avoids risky video states when a failed mode-setting process has to be undone ("rollback").{{r|Reding 2015|p=9}} Atomic mode-setting allows one to know beforehand if certain specific mode configuration is appropriate, by providing mode testing capabilities.{{r|Vetter 2015 LWN p1}} When an atomic mode is tested and its validity confirmed, it can be applied with a single indivisible (atomic) [[Atomic commit|commit]] operation. Both test and commit operations are provided by the same new [[ioctl]] with different flags. ''Atomic page flip'' on the other hand allows to update multiple planes on the same output (for instance the primary plane, the cursor plane and maybe some overlays or secondary planes) all synchronized within the same [[Vertical blanking interval|VBLANK]] interval, ensuring a proper display without tearing.{{r|Reding 2015|p=9,14}}{{r|Vetter 2015 LWN p1}} This requirement is especially relevant to mobile and embedded display controllers, that tend to use multiple planes/overlays to save power. The new atomic API is built upon the old KMS API. It uses the same model and objects (CRTCs, encoders, connectors, planes, ...), but with an increasing number of object properties that can be modified.{{r|Vetter 2015 LWN p1}} The atomic procedure is based on changing the relevant properties to build the state that we want to test or commit. The properties we want to modify depend on whether we want to do a mode-setting (mostly CRTCs, encoders and connectors properties) or page flipping (usually planes properties). The ioctl is the same for both cases, the difference being the list of properties passed with each one.{{r|Vetter 2015 LWN p2}} === Render nodes === In the original DRM API, the DRM device <code>/dev/dri/card''X''</code> is used for both privileged (modesetting, other display control) and non-privileged (rendering, [[GPGPU]] compute) operations.{{r|Herrmann 2013 DRM split}} For security reasons, opening the associated DRM device file requires special privileges "equivalent to root-privileges".{{r|Herrmann 2013 rendernodes}} This leads to an architecture where only some reliable user space programs (the X server, a graphical compositor, ...) have full access to the DRM API, including the privileged parts like the modeset API. Other user space applications that want to render or make GPGPU computations should be granted by the owner of the DRM device ("DRM Master") through the use of a special authentication interface.{{r|drmbook-rendernodes}} Then the authenticated applications can render or make computations using a restricted version of the DRM API without privileged operations. This design imposes a severe constraint: there must always be a running graphics server (the X Server, a Wayland compositor, ...) acting as DRM-Master of a DRM device so that other user space programs can be granted the use of the device, even in cases not involving any graphics display like GPGPU computations.{{r|Herrmann 2013 rendernodes}}{{r|drmbook-rendernodes}} The "render nodes" concept tries to solve these scenarios by splitting the DRM user space API into two interfaces – one privileged and one non-privileged – and using separate device files (or "nodes") for each one.{{r|Herrmann 2013 DRM split}} For every GPU found, its corresponding DRM driver—if it supports the render nodes feature—creates a device file <code>/dev/dri/renderD''X''</code>, called the ''render node'', in addition to the primary node <code>/dev/dri/card''X''</code>.{{r|drmbook-rendernodes}}{{r|Herrmann 2013 DRM split}} Clients that use a direct rendering model and applications that want to take advantage of the computing facilities of a GPU, can do it without requiring additional privileges by simply opening any existing render node and dispatching GPU operations using the limited subset of the DRM API supported by those nodes—provided they have [[file system permissions]] to open the device file. Display servers, compositors and any other program that requires the modeset API or any other privileged operation must open the standard primary node that grants access to the full DRM API and use it as usual. Render nodes explicitly disallow the GEM ''flink'' operation to prevent buffer sharing using insecure GEM global names; only PRIME (DMA-BUF) [[file descriptor]]s can be used to share buffers with another client, including the graphics server.{{r|Herrmann 2013 DRM split}}{{r|drmbook-rendernodes}} == Hardware support == {{Main article|Free and open-source graphics device driver}} [[File:Linux AMD graphics stack.svg|thumb|DRM is to be used by user-mode graphics devices driver, like e.g. [[AMD Catalyst]] or [[Mesa 3D]]. User-space programs use the [[Linux API|Linux System Call Interface]] to access DRM. DRM augments the Linux System Call Interface with own system calls.{{r|Deucher amdgpu}}]] The Linux DRM subsystem includes [[Free and open-source software|free and open-source]] drivers to support hardware from the 3 main manufacturers of GPUs for desktop computers (AMD, NVIDIA and Intel), as well as from a growing number of mobile GPU and [[System on a chip]] (SoC) integrators. The quality of each driver varies highly, depending on the degree of cooperation by the manufacturer and other matters. {| class="wikitable sortable" style="text-align:center" |+ DRM drivers |- ! Driver ! Since kernel ! Supported hardware ! Vendor support ! Status/Notes |- | radeon | 2.4.1 | style="text-align:left;"| [[Advanced Micro Devices|AMD]] (formerly ATi) [[Radeon]] GPU series with the architectures [[TeraScale (microarchitecture)|TeraScale]] and [[Graphics Core Next#first|GCN 1st]] & [[Graphics Core Next#second|2nd gen]]. Including models from [[Radeon R100 series|R100]]/[[Radeon R200 series|200]]/[[Radeon R300 series|300]]/[[Radeon R400 series|400]], [[Radeon X1000 series|Radeon X1000]], [[Radeon HD 2000 series|HD 2000]]/[[Radeon HD 4000 series|4000]]/[[Radeon HD 5000 series|5000]]/[[Radeon HD 6000 series|6000]]/[[Radeon HD 7000 series|7000]]/[[Radeon HD 8000 series|8000]], R5/R7/R9 [[AMD Radeon Rx 200 series|200]]/[[AMD Radeon Rx 300 series|300]] series and [[AMD Accelerated Processing Unit#Steamroller architecture .282014.29: Kaveri|Kaveri]] APUs. | {{yes}} | {{active}} |- | i915 | 2.6.9 | style="text-align:left;"| [[Intel GMA]] 830M, 845G, 852GM, 855GM, 865G, 915G, 945G, 965G, G35, G41, G43, G45 chipsets. [[Intel HD and Iris Graphics]] HD Graphics 2000/3000/2500/4000/4200/4400/4600/P4600/P4700/5000, Iris Graphics 5100, Iris Pro Graphics 5200 integrated GPUs. | {{yes}} | {{active}} |- | [[Nouveau (software)|nouveau]] | 2.6.33{{r|Kernelnewbies nouveau}}{{r|nouveau merge}} | style="text-align:left;"| [[NVIDIA]] [[Tesla (microarchitecture)|Tesla]], [[Fermi (microarchitecture)|Fermi]], [[Kepler (microarchitecture)|Kepler]], [[Maxwell (microarchitecture)|Maxwell]] based [[GeForce]] GPUs, [[Tegra K1]], [[Tegra X1|X1]] SoC | {{partial}} | {{active}} |- | exynos | 3.2{{r|exynos merge}} | style="text-align:left;"| [[Samsung Electronics|Samsung]] ARM-based Exynos SoCs | | |- | vmwgfx | 3.2 (from staging){{r|vmwgfx merge}} | style="text-align:left;"| Virtual GPU for the [[VMware Workstation|VMware]] SVGA2 | | virtual driver |- | gma500 | 3.3 (from staging){{r|Kernelnewbies gma500}}{{r|Larabel linux 3.3}} | style="text-align:left;"| Intel [[GMA 500]] and other [[Imagination Technologies]] ([[PowerVR]]) based graphics GPUs | | experimental 2D KMS-only driver |- | ast | 3.5{{r|ast merge}} | style="text-align:left;"| ASpeed Technologies 2000 series | | experimental |- | mgag200 | 3.5<ref>{{cite web |title=mgag200: initial g200se driver (v2) |url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=414c453106255b11df77ed6b08eedb6d2369c338 |first=Dave |last=Airlie |date=17 May 2012 |access-date=24 January 2018}}</ref> | style="text-align:left;"| [[Matrox]] MGA-G200 server display engines | | KMS-only |- | shmobile | 3.7{{r|shmobile merge}} | style="text-align:left;"| [[Renesas Electronics|Renesas]] SH Mobile | | |- | tegra | 3.8{{r|tegra merge}} | style="text-align:left;"| [[Nvidia]] [[Tegra]]20, Tegra30 SoCs | {{yes}} | {{active}} |- | omapdrm | 3.9{{r|omapdrm merge}} | style="text-align:left;"| [[Texas Instruments]] [[OMAP]]5 SoCs | | |- | rcar-du | 3.11{{r|rcar merge}} | style="text-align:left;"| [[Renesas Electronics|Renesas]] R-Car SoC Display Units | | |- | msm | 3.12{{r|msm merge}}{{r|Larabel msm}} | style="text-align:left;"| [[Qualcomm]]'s [[Adreno]] A2xx/A3xx/A4xx GPU families ([[Qualcomm Snapdragon|Snapdragon]] SOCs){{r|Edge freedreno}} | | |- | armada | 3.13{{r|Russell armada}}{{r|armada merge}} | style="text-align:left;"| [[Marvell Technology Group|Marvell]] Armada 510 SoCs | | |- | bochs | 3.14{{r|bochs merge}} | style="text-align:left;"| Virtual [[VGA]] cards using the [[Bochs]] dispi vga interface (such as [[QEMU]] stdvga) | | virtual driver |- | sti | 3.17{{r|Larabel sti}}{{r|Corbet linux 3.17}} | style="text-align:left;"| [[STMicroelectronics]] SoC stiH41x series | | |- | imx | 3.19 (from staging){{r|Corbet linux 3.19}}{{r|imx merge}} | style="text-align:left;"| [[Freescale]] [[i.MX]] SoCs | | |- | rockchip | 3.19{{r|Corbet linux 3.19}}{{r|rockchip merge}} | style="text-align:left;"| [[Rockchip]] SoC-based GPUs | | KMS-only |- | amdgpu{{r|Deucher amdgpu}} | 4.2{{r|Larabel linux 4.2}}{{r|Corbet linux 4.2}} | style="text-align:left;"| [[Advanced Micro Devices|AMD]] [[Radeon]] GPU series with the architectures [[Graphics Core Next#third|GCN 3rd]] & [[Graphics Core Next#fourth|4th gen]]. Including models from Radeon [[AMD Radeon Rx 200 series|Rx 200]]/[[AMD Radeon Rx 300 series|300]]/[[AMD Radeon 400 series|400]]/[[AMD Radeon 500 series|500]]{{r|Deucher amdgpu fiji}} series and [[AMD Accelerated Processing Unit#Puma.2B architecture .282015.29: Carrizo-L .28laptop and mobile processors.29|Carrizo]] and [[AMD Accelerated Processing Unit#Excavator architecture .282016.29: Bristol Ridge and Stoney Ridge|Bristol & Stoney Ridge]] APUs. | {{yes}} | {{active}} |- | virtio | 4.2{{r|virtio merge}} | style="text-align:left;"| Virtual GPU driver for [[QEMU]] based virtual machine managers (like [[Kernel-based Virtual Machine|KVM]] or [[Xen]]) | | virtual driver |- | vc4 | 4.4{{r|Corbet linux 4.4}}{{r|Larabel linux 4.4}}{{r|vc4 merge}} | style="text-align:left;"| [[Raspberry Pi]]'s [[Broadcom]] BCM2835 and BCM2836 SoCs ([[VideoCore]] IV GPU) | | |- | etnaviv | 4.5{{r|Kernelnewbies etnaviv}}{{r|Larabel linux 4.5}}{{r|Corbet linux 4.5}} | style="text-align:left;"| [[Vivante]] GPU cores found in several SoCs such as [[Marvell Technology Group|Marvell]] ARMADA and Freescale [[I.MX#i.MX6x series|i.MX6 Series]] | | |- | sun4i | 4.7{{r|sun4i merge}}{{r|Airlie linux 4.7}} | style="text-align:left;"| [[Allwinner]] SoCs (ARM [[Mali (GPU)|Mali-400]] GPU) | | |- | kirin | 4.7{{r|hisilicon merge}}{{r|Airlie linux 4.7}} | style="text-align:left;"| [[HiSilicon]] Kirin hi6220 SoC (ARM [[Mali (GPU)|Mali 450-MP4]] GPU) | | |- | mediatek | 4.7{{r|mediatek merge}}{{r|Airlie linux 4.7}} | style="text-align:left;"| [[MediaTek]] MT8173 SoC (Imagination [[PowerVR]] GX6250 GPU) | | |- | hibmc | 4.10<ref>{{cite web|title=Hisilicon Hibmc DRM Driver Being Added For Linux 4.10 |url=https://www.phoronix.com/scan.php?page=news_item&px=Hisilicon-Hibmc-DRM-Linux-4.10 |first=Michael |last=Larabel |work=[[Phoronix]] |date=22 November 2016 |access-date=24 January 2018}}</ref> | style="text-align:left;"| HiSilicon hi1710 [[Huawei]] [[Baseboard management controller|iBMC]] SoC ([[Silicon Image]] SM750 GPU core<ref>{{cite web |title=Huawei FusionServer RH5885 V3 Technical White Paper |url=http://e-file.huawei.com/en/material/MaterialDownload?materialid=77d7cd3156c646abbcbaaa20cd4f0358 |quote=uses an onboard display chip that is integrated into the management chip Hi1710 and uses the IP core of the SM750 |date=18 November 2016|archive-url = https://web.archive.org/web/20180125015931/http://e-file.huawei.com/en/material/MaterialDownload?materialid=77d7cd3156c646abbcbaaa20cd4f0358|archive-date = 2018-01-25}}</ref>) | | KMS-only |- | vkms | 4.19<ref name="vkms merge">{{Cite web|url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1c7c5fd916a0ff66501467f1e8e79d3ff8eca112|title=drm/vkms: Introduce basic VKMS driver|website=git.kernel.org|access-date=2022-07-20}}</ref><ref name="phoronix-2018-08-15">{{cite web|title=Virtual Kernel Mode-Setting Driver Being Added To Linux 4.19 |url=https://www.phoronix.com/scan.php?page=news_item&px=Virtual-KMS-VKMS-Linux-4.19 |first=Michael |last=Larabel |work=[[Phoronix]] |date=15 August 2018 |access-date=20 July 2022}}</ref> | style="text-align:left;"| Software-only model of a KMS driver that is useful for testing and for running [[X Window System|X]] (or similar) on [[headless machine]]s. | | virtual driver, experimental |- | lima | 5.2<ref name="lima merge">{{Cite web|url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/lima?id=a1d2a6339961efc078208dc3b2f006e9e9a8e119|title=kernel/git/torvalds/linux.git - Linux kernel source tree|website=git.kernel.org|access-date=2019-11-28}}</ref><ref name="phoronix-2019-05-09" /> | style="text-align:left;"| [[Mali (GPU)|ARM Mali]] 4xx GPUs | | |- | panfrost | 5.2<ref name="panfrost merge">{{Cite web|url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/panfrost?id=f3ba91228e8e917e5bd6c4b72bfe846933d17370|title=kernel/git/torvalds/linux.git - Linux kernel source tree|website=git.kernel.org|access-date=2019-11-28}}</ref><ref name="phoronix-2019-05-09" /> | style="text-align:left;"| ARM Mali Txxx (Midgard) and Gxx (Bifrost) GPUs | | |- | vboxvideo | 5.2 (from staging)<ref name="vboxvideo merge">{{Cite web|url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=131abc56e1bacef23cb7b340519d36e2f5adb2a9|title=drm/vboxvideo: Move the vboxvideo driver out of staging|website=git.kernel.org|access-date=2022-07-20}}</ref><ref name="phoronix-2019-05-09">{{cite web|title=Linux 5.2 DRM Makes Icelake Production-Ready, Adds Lima & Panfrost Drivers |url=https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.2-DRM-Update |first=Michael |last=Larabel |work=[[Phoronix]] |date=9 May 2019 |access-date=20 July 2022}}</ref> | style="text-align:left;"| Virtual GPU driver for [[VirtualBox]] (VBoxVGA GPU) | | virtual driver |- | hyperv_drm | 5.14<ref name="hyperv-drm merge">{{Cite web|url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76c56a5affeba1e163b66b9d8cc192e6154466f0|title=drm/hyperv: Add DRM driver for hyperv synthetic video device|website=git.kernel.org|access-date=2021-08-30}}</ref><ref>{{cite web|title=Microsoft's Hyper-V DRM Display Driver Will Land For Linux 5.14 |url=https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.14-Hyper-V-Display |first=Michael |last=Larabel |work=[[Phoronix]] |date=9 June 2021 |access-date=30 August 2021}}</ref> | style="text-align:left;"| Virtual GPU driver for [[Hyper-V]] synthetic video device | | virtual driver |- | simpledrm | 5.14<ref name="simpledrm merge">{{Cite web|url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=11e8f5fd223bd4d33fa10527bad3fe48469a15df|title=drm: Add simpledrm driver|website=git.kernel.org|access-date=2021-08-30}}</ref><ref>{{cite web|title=Linux 5.14 To Bring SimpleDRM Driver, VC4 HDR, Marks More AGP Code As Legacy |url=https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.14-Initial-DRM-Misc |first=Michael |last=Larabel |work=[[Phoronix]] |date=13 May 2021 |access-date=30 August 2021}}</ref> | style="text-align:left;"| GPU Driver for firmware-provided framebuffers ([[UEFI GOP]], [[VESA BIOS Extensions]], [[embedded system]]s) | | |- | ofdrm | 6.2<ref name="ofdrm merge">{{Cite web|url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c8a17756c42581ba1a567d1dd3b69e8f5619a7d8|title=drm/ofdrm: Add ofdrm for Open Firmware framebuffers|website=git.kernel.org|access-date=21 February 2023}}</ref><ref>{{cite web|title=Open Firmware DRM Driver "OFDRM" Queuing For Linux 6.2 |url=https://www.phoronix.com/news/Linux-6.2-OFDRM |first=Michael |last=Larabel |work=[[Phoronix]] |date=20 October 2022 |access-date=21 February 2023}}</ref> | style="text-align:left;"| GPU Driver for [[Open Firmware]] framebuffers | | |- | loongson | 6.6<ref name="loongson merge">{{Cite web|url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f39db26c54281da6a785259498ca74b5e470476f|title=drm: Add kms driver for loongson display controller|website=git.kernel.org|access-date=23 February 2024}}</ref><ref>{{cite web|title=Open-Source Graphics Driver Updates Begin Queuing For Linux 6.6 |url=https://www.phoronix.com/news/Linux-6.6-Initial-DRM-Misc-Next |first=Michael |last=Larabel |work=[[Phoronix]] |date=13 July 2023 |access-date=23 February 2024}}</ref> | style="text-align:left;"| GPU Driver for [[Loongson]] GPUs and SoCs | | |- | powervr | 6.8<ref name="powervr merge">{{Cite web|url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4babef0708656c54e67ee0ee3994ee98898f51d1|title=drm/imagination: Add skeleton PowerVR driver|website=git.kernel.org|access-date=27 May 2024}}</ref><ref>{{cite web|title=Imagination PowerVR Open-Source GPU Driver To Be Introduced In Linux 6.8 |url=https://www.phoronix.com/news/Imagination-PVR-Linux-6.8-DRM |first=Michael |last=Larabel |work=[[Phoronix]] |date=23 November 2023 |access-date=27 May 2024}}</ref> | style="text-align:left;"| [[Imagination Technologies]] [[PowerVR]] ([[PowerVR#Series6 (Rogue)|Series 6]] and later) & IMG Graphics GPUs | | |- | xe | 6.8<ref name="xe merge">{{Cite web|url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=dd08ebf6c3525a7ea2186e636df064ea47281987|title=drm/xe: Introduce a new DRM driver for Intel GPUs|website=git.kernel.org|access-date=27 May 2024}}</ref><ref>{{cite web|title=Intel's New "Xe" Kernel Graphics Driver Submitted Ahead Of Linux 6.8 |url=https://www.phoronix.com/news/Intel-Xe-Submission-Linux-6.8 |first=Michael |last=Larabel |work=[[Phoronix]] |date=15 December 2023 |access-date=27 May 2024}}</ref> | style="text-align:left;"| [[Intel Xe]] series GPUs ([[Intel Graphics Technology#Xe-LP architecture (Gen12)|Gen12]] integrated GPUs, [[Intel Arc]] discrete GPUs) | {{yes}} | experimental |} There is also a number of drivers for old, obsolete hardware detailed in the next table for historical purposes. {| class="wikitable" style="text-align:center" |+ Historic DRM drivers |- ! Driver ! Since kernel ! Supported hardware ! Status/Notes |- | gamma | 2.3.18 | style="text-align:left;"| [[3Dlabs]] GLINT GMX 2000 | Removed since 2.6.14{{r|gamma remove}} |- | ffb | 2.4 | style="text-align:left;"| Creator/Creator3D (used by [[Sun Microsystems]] [[Sun Ultra series|Ultra]] workstations) | Removed since 2.6.21{{r|ffb remove}} |- | tdfx | 2.4 | style="text-align:left;"| [[3dfx Interactive|3dfx]] Banshee/[[Voodoo3]]+ | Removed since 6.3<ref name="tdfx remove">{{cite web|title=drm: Remove the obsolete driver-tdfx|url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cfc8860eacec5da2ee2880c502b10daf196c6cbb|website=Kernel.org|access-date=23 February 2024}}</ref> |- | mga | 2.4 | style="text-align:left;"| [[Matrox]] [[Matrox G200|G200]]/[[Matrox G400|G400]]/G450 | Removed since 6.3<ref name="mga remove">{{cite web|title=drm: Remove the obsolete driver-mga|url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96ed7db55bef1db201aaaef2761416c4e64e1245|website=Kernel.org|access-date=23 February 2024}}</ref> |- | r128 | 2.4 | style="text-align:left;"| [[ATI Rage 128]] | Removed since 6.3<ref name="r128 remove">{{cite web|title=drm: Remove the obsolete driver-r128|url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=28483b8666bfe7d0ec34cfc492d77e64f97f6de1|website=Kernel.org|access-date=23 February 2024}}</ref> |- | i810 | 2.4 | style="text-align:left;"| [[Intel i810]] | Removed since 6.3<ref name="i810 remove">{{cite web|title=drm: Remove the obsolete driver-i810|url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cab18866feade5ffa0cadc5e632528b2050e8e28|website=Kernel.org|access-date=23 February 2024}}</ref> |- | sis | 2.4.17 | style="text-align:left;"| [[Silicon Integrated Systems|SiS]] [[SiS 300|300]]/630/540 | Removed since 6.3<ref name="sis remove">{{cite web|title=drm: Remove the obsolete driver-sis|url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=20efabc2e80be1df79510b8be9ca004d3ce9be11|website=Kernel.org|access-date=23 February 2024}}</ref> |- | i830 | 2.4.20 | style="text-align:left;"| Intel 830M/845G/852GM/855GM/865G | style="width:200px;"|Removed since 2.6.39{{r|i830 remove}} (replaced by i915 driver) |- | via | 2.6.13{{r|unichrome merge}} | style="text-align:left;"| [[VIA Technologies|VIA]] [[Unichrome]] / Unichrome Pro | Removed since 6.3<ref name="unichrome remove">{{cite web|title=drm: Remove the obsolete driver-via|url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8391e000065d4fac88548e071fc43c3e07cb7047|website=Kernel.org|access-date=23 February 2024}}</ref> |- | savage | 2.6.14{{r|savage merge}} | style="text-align:left;"| [[S3 Graphics]] [[S3 Savage|Savage]] 3D/MX/IX/4/SuperSavage/Pro/Twister | Removed since 6.3<ref name="savage remove">{{cite web|title=drm: Remove the obsolete driver-savage|url=https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7872bc2cb13e4dd83d193d50a835e179f449ab07|website=Kernel.org|access-date=23 February 2024}}</ref> |} == Development == The Direct Rendering Manager is developed within the [[Linux kernel]], and its [[source code]] resides in the <code>/drivers/gpu/drm</code> directory of the Linux source code. The subsystem maintainer is Dave Airlie, with other maintainers taking care of specific drivers.{{r|linux maintainers}} As usual in the Linux kernel development, DRM submaintainers and contributors send their [[patch (Unix)|patches]] with new features and [[Software bug|bug]] fixes to the main DRM maintainer which integrates them into its own Linux [[Repository (revision control)|repository]]. The DRM maintainer in turn submits all of these patches that are ready to be mainlined to [[Linus Torvalds]] whenever a new Linux version is going to be released. Torvalds, as top maintainer of the whole kernel, holds the last word on whether a patch is suitable or not for inclusion in the kernel. For historical reasons, the source code of the libdrm library is maintained under the umbrella of the [[Mesa (computer graphics)|Mesa]] project.{{r|libdrm git}} == History == In 1999, while developing [[Direct Rendering Infrastructure|DRI]] for [[XFree86]], Precision Insight created the first version of DRM for the [[3dfx]] video cards, as a [[Linux kernel]] [[Patch (computing)|patch]] included within the [[Mesa (computer graphics)|Mesa]] source code.{{r|Mesa 3dfx}} Later that year, the DRM code was mainlined in Linux kernel 2.3.18 under the <code>/drivers/char/drm/</code> directory for [[character device]]s.{{r|Linux 2.3.18pre1}} During the following years the number of supported video cards grew. When Linux 2.4.0 was released in January 2001 there was already support for Creative Labs GMX 2000, Intel i810, Matrox G200/G400 and ATI Rage 128, in addition to 3dfx Voodoo3 cards,{{r|Linux 2.4.0}} and that list expanded during the 2.4.x series, with drivers for [[ATI Radeon]] cards, some SiS video cards and Intel 830M and subsequent integrated GPUs. The split of DRM into two components, DRM core and DRM driver, called ''DRM core/personality split'' was done during the second half of 2004,{{r|Airlie redesign}}{{r|Airlie DRM split}} and merged into kernel version 2.6.11.{{r|Torvalds linux 2.6.11-rc1}} This split allowed multiple DRM drivers for multiple devices to work simultaneously, opening the way to multi-GPU support. The idea of putting all the video mode setting code in one place inside the kernel had been acknowledged for years,{{r|Gettys Packard 2004}}{{r|Smirl 2005}} but the graphics card manufacturers had argued that the only way to do the mode-setting was to use the routines provided by themselves and contained in the [[Video BIOS]] of each graphics card. Such code had to be executed using x86 [[real mode]], which prevented it from being invoked by a kernel running in [[protected mode]].{{r|Packard 2007}} The situation changed when Luc Verhaegen and other developers found a way to do the mode-setting natively instead of BIOS-based,{{r|Verhaegen 2006}}{{r|Packard 2007}} showing that it was possible to do it using normal kernel code and laying the groundwork for what would become ''Kernel Mode Setting''. In May 2007 Jesse Barnes ([[Intel]]) published the first proposal for a ''drm-modesetting'' API and a working native implementation of mode-setting for Intel GPUs within the i915 DRM driver.{{r|Barnes modesetting}} In December 2007 Jerome Glisse started to add the native mode-setting code for ATI cards to the radeon DRM driver.{{r|Glisse 2007}}{{r|Larabel 2008 KMS}} Work on both the API and drivers continued during 2008, but got delayed by the necessity of a memory manager also in kernel space to handle the framebuffers.{{r|Packard 2008 status}} In October 2008 the Linux kernel 2.6.27 brought a major [[source code]] reorganization, prior to some significant upcoming changes. The DRM source code tree was moved to its own source directory <code>/drivers/gpu/drm/</code> and the different drivers were moved into their own subdirectories. Headers were also moved into a new <code>/include/drm</code> directory.{{r|reorganization commit}} The increasing complexity of video memory management led to several approaches to solving this issue. The first attempt was the ''Translation Table Maps'' (TTM) memory manager, developed by Thomas Hellstrom ([[Tungsten Graphics]]) in collaboration with Emma Anholt (Intel) and Dave Airlie ([[Red Hat]]).{{r|Corbet 2007}} TTM was proposed for inclusion into mainline kernel 2.6.25 in November 2007,{{r|Corbet 2007}} and again in May 2008, but was ditched in favor of a new approach called ''Graphics Execution Manager'' (GEM).{{r|Corbet 2008}} GEM was first developed by Keith Packard and Emma Anholt from Intel as a simpler solution for memory management for their i915 driver.{{r|Packard Anholt 2008}} GEM was well received and merged into the Linux kernel version 2.6.28 released in December 2008.{{r|Kernelnewbies linux 2.6.28}} Meanwhile, TTM had to wait until September 2009 to be finally merged into Linux 2.6.31 as a requirement of the new Radeon KMS DRM driver.{{r|TTM commit}} With memory management in place to handle buffer objects, DRM developers could finally add to the kernel the already finished API and code to do [[mode setting]]. This expanded API is what is called ''Kernel Mode-setting'' (KMS) and the drivers which implement it are often referred to as ''KMS drivers''. In March 2009, KMS was merged into the Linux kernel version 2.6.29,{{r|Kernelnewbies linux 2.6.29}}{{r|KMS commit}} along with KMS support for the i915 driver.{{r|KMS i915 commit}} The KMS API has been exposed to user space programs since libdrm 2.4.3.{{r|libdrm 2.4.3}} The userspace [[X.Org Server|X.Org DDX]] driver for Intel graphics cards was also the first to use the new GEM and KMS APIs.{{r|xf86-video-intel 2.5.0}} KMS support for the radeon DRM driver was added to Linux 2.6.31 release of September 2009.{{r|Kernelnewbies linux 2.6.31}}{{r|Torvalds linux 2.6.31}}{{r|KMS radeon commit}} The new radeon KMS driver used the TTM memory manager but exposed GEM-compatible interfaces and ioctls instead of TTM ones.{{r|Larabel 2008 gem-ttm}} Since 2006 the [[nouveau (software)|nouveau project]] had been developing a [[free software]] DRM driver for [[NVIDIA]] GPUs outside of the official Linux kernel. In 2010 the nouveau source code was merged into Linux 2.6.33 as an experimental driver.{{r|Kernelnewbies nouveau}}{{r|nouveau merge}} At the time of merging, the driver had been already converted to KMS, and behind the GEM API it used TTM as its memory manager.{{r|nouveau 40}} The new KMS API—including the GEM API—was a big milestone in the development of DRM, but it didn't stop the API from being enhanced in the following years. KMS gained support for [[Page flipping|page flips]] in conjunction with asynchronous [[Vertical blanking interval|VBLANK]] notifications in Linux 2.6.33{{r|Kernelnewbies linux 2.6.33}}{{r|pageflip commit}}—only for the i915 driver, radeon and nouveau added it later during Linux 2.6.38 release.{{r|Kernelnewbies linux 2.6.38}} The new page flip interface was added to libdrm 2.4.17.{{r|libdrm 2.4.17}} In early 2011, during the Linux 2.6.39 release cycle, the so-called ''dumb buffers''—a hardware-independent non-accelerated way to handle simple buffers suitable for use as framebuffers—were added to the KMS API.{{r|dumb-buffers commit}}{{r|Kernelnewbies linux 2.6.39}} The goal was to reduce the complexity of applications such as [[Plymouth (software)|Plymouth]] that don't need to use special accelerated operations provided by driver-specific ioctls.{{r|drmbook-modesetting}} The feature was exposed by libdrm from version 2.4.25 onwards.{{r|libdrm 2.4.25}} Later that year it also gained a new main type of objects, called ''planes''. Planes were developed to represent hardware overlays supported by the scanout engine.{{r|Barnes 2011 overlays}}{{r|Barnes 2011 planes}} Plane support was merged into Linux 3.3.{{r|planes commit}} and libdrm 2.4.30. Another concept added to the API—during Linux 3.5{{r|properties commit}} and libdrm 2.4.36{{r|libdrm 2.4.36}} releases—were ''generic object properties'', a method to add generic values to any KMS object. Properties are specially useful to set special behaviour or features to objects such as CRTCs and planes. An early proof of concept to provide GPU offloading between DRM drivers was developed by Dave Airlie in 2010.{{r|Airlie 2010}}{{r|Larabel 2010 PRIME}} Since Airlie was trying to mimic the [[NVIDIA Optimus]] technology, he decided to name it "PRIME".{{r|Airlie 2010}} Airlie resumed his work on PRIME in late 2011, but based on the new [[DMA-BUF]] buffer sharing mechanism introduced by Linux kernel 3.3.{{r|Larabel 2012 PRIME}} The basic DMA-BUF PRIME infrastructure was finished in March 2012{{r|Airlie PRIME patch}} and merged into the Linux 3.4 release,{{r|Larabel 2012 PRIME 3.4}}{{r|PRIME commit}}{{r|Kernelnewbies linux 3.4}} as well as into libdrm 2.4.34.{{r|libdrm 2.4.34}} Later during the Linux 3.5 release, several DRM drivers implemented PRIME support, including i915 for Intel cards, radeon for AMD cards and nouveau for NVIDIA cards.{{r|Larabel 2012 PRIME 3.5}}{{r|Kernelnewbies linux 3.5}} In recent years, the DRM API has incrementally expanded with new and improved features. In 2013, as part of [[Google Summer of Code|GSoC]], David Herrmann developed the multiple ''render nodes'' feature.{{r|Herrmann 2013 rendernodes}} His code was added to the Linux kernel version 3.12 as an experimental feature{{r|Corbet linux 3.12}}{{r|rendernodes commit}} supported by i915,{{r|rendernodes i915}} radeon{{r|rendernodes radeon}} and nouveau{{r|rendernodes nouveau}} drivers, and enabled by default since Linux 3.17.{{r|Corbet linux 3.17}} In 2014 Matt Roper (Intel) developed the ''universal planes'' (or ''unified planes'') concept by which framebuffers (''primary planes''), overlays (''secondary planes'') and cursors (''cursor planes'') are all treated as a single type of object with an unified API.{{r|Roper 2014}} Universal planes support provides a more consistent DRM API with fewer, more generic [[ioctl]]s.{{r|Paalanen 2014}} In order to maintain the API [[backward compatibility|backwards compatible]], the feature is exposed by DRM core as an additional capability that a DRM driver can provide. Universal plane support debuted in Linux 3.15{{r|Larabel 2014 planes}} and libdrm 2.4.55.{{r|libdrm 2.4.55}} Several drivers, such as the Intel i915,{{r|Vetter linux 3.17}} have already implemented it. The most recent DRM API enhancement is the ''atomic mode-setting'' API, which brings [[Atomicity (programming)|atomicity]] to the mode-setting and page flipping operations on a DRM device. The idea of an atomic API for mode-setting was first proposed in early 2012.{{r|Barnes atomic}} Ville Syrjälä (Intel) took over the task of designing and implementing such atomic API.{{r|Syrjala 2012 atomic}} Based on his work, Rob Clark ([[Texas Instruments]]) took a similar approach aiming to implement atomic page flips.{{r|Clark 2012 atomic}} Later in 2013 both proposed features were reunited in a single one using a single ioctl for both tasks.{{r|Clark 2013 atomic}} Since it was a requirement, the feature had to wait for the support of universal planes to be merged in mid-2014.{{r|Vetter linux 3.17}} During the second half of 2014 the atomic code was greatly enhanced by Daniel Vetter (Intel) and other DRM developers{{r|Vetter 2016 atomic|p=18}} in order to facilitate the transition for the existing KMS drivers to the new atomic framework.{{r|Vetter 2014 atomic}} All of this work was finally merged into Linux 3.19{{r|Airlie linux 3.19}} and Linux 4.0{{r|Vetter 2015 atomic}}{{r|Airlie linux 4.0}}{{r|Kernelnewbies linux 4.0}} releases, and enabled by default since Linux 4.2.{{r|Kernelnewbies linux 4.2}} libdrm exposed the new atomic API since version 2.4.62.{{r|libdrm 2.4.62}} Multiple drivers have already been converted to the new atomic API.{{r|Vetter 2016 atomic update}} By 2018 ten new DRM drivers based on this new atomic model had been added to the Linux kernel.{{r|Stone 2018}} == Adoption == The Direct Rendering Manager kernel subsystem was initially developed to be used with the new [[Direct Rendering Infrastructure]] of the [[XFree86]] 4.0 display server, later inherited by its successor, the [[X.Org Server]]. Therefore, the main users of DRM were DRI clients that link to the hardware-accelerated [[OpenGL]] implementation that lives in the [[Mesa 3D]] library, as well as the X Server itself. Nowadays DRM is also used by several [[Wayland (display server protocol)|Wayland compositors]], including [[Weston (display server)|Weston]] reference compositor. [[kmscon]] is a virtual console implementation that runs in user space using DRM KMS facilities.{{r|Herrmann 2012 kmscon}} In 2015, version 358.09 (beta) of the proprietary [[Nvidia GeForce driver]] received support for the DRM mode-setting interface implemented as a new kernel blob called <code>nvidia-modeset.ko</code>. This new driver component works in conjunction with the <code>nvidia.ko</code> kernel module to program the display engine (i.e. display controller) of the GPU.<ref name="beta358.09">{{cite web |url=https://devtalk.nvidia.com/default/topic/884727/linux-solaris-and-freebsd-driver-358-09-beta-/?offset=1 |title=Linux, Solaris, and FreeBSD driver 358.09 (beta) |date=2015-12-10}}</ref> == See also == {{Portal|Linux|Free and open-source software}} * [[Direct Rendering Infrastructure]] * [[Free and open-source graphics device driver]] * [[Linux framebuffer]] == References == {{reflist|30em|refs= <!-- documentation --> <ref name="drmbook-init">{{cite web|last1=Barnes|first1=Jesse|last2=Pinchart|first2=Laurent|last3=Vetter|first3=Daniel|last4=Wunner|first4=Lukas|title=Linux GPU Driver Developer's Guide - Driver Initialization|url=https://dri.freedesktop.org/docs/drm/gpu/drm-internals.html#driver-features|access-date=31 August 2016}}</ref> <ref name="drmbook-mm">{{cite web|last1=Barnes|first1=Jesse|last2=Pinchart|first2=Laurent|last3=Vetter|first3=Daniel|last4=Wunner|first4=Lukas|title=Linux GPU Driver Developer's Guide - Memory management|url=https://dri.freedesktop.org/docs/drm/gpu/drm-mm.html|access-date=31 August 2016}}</ref> <ref name="drmbook-kms">{{cite web|last1=Barnes|first1=Jesse|last2=Pinchart|first2=Laurent|last3=Vetter|first3=Daniel|last4=Wunner|first4=Lukas|title=Linux GPU Driver Developer's Guide - KMS Initialization and Cleanup|url=https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#kms-initialization-and-cleanup|access-date=31 August 2016}}</ref> <ref name="drmbook-modesetting">{{cite web|last1=Barnes|first1=Jesse|last2=Pinchart|first2=Laurent|last3=Vetter|first3=Daniel|last4=Wunner|first4=Lukas|title=Linux GPU Driver Developer's Guide - Dumb Buffer Objects|url=https://dri.freedesktop.org/docs/drm/gpu/drm-kms.html#dumb-buffer-objects|access-date=31 August 2016}}</ref> <ref name="drmbook-rendernodes">{{cite web|last1=Barnes|first1=Jesse|last2=Pinchart|first2=Laurent|last3=Vetter|first3=Daniel|last4=Wunner|first4=Lukas|title=Linux GPU Driver Developer's Guide - Render nodes|url=https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#render-nodes|access-date=31 August 2016}}</ref> <ref name="DRM readme">{{cite web|title=Linux kernel/drivers/gpu/drm/README.drm |url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/README.drm |archive-url=https://archive.today/20140226185421/https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/README.drm |url-status=dead |archive-date=2014-02-26 |work=[[kernel.org]] |access-date=2014-02-26 }}</ref> <ref name="libdrm README">{{cite web|title=README.rst - mesa/drm - Direct Rendering Manager headers and kernel modules|url=https://cgit.freedesktop.org/mesa/drm/tree/README.rst|date= 2020-03-21|archive-url=https://archive.today/20200321143932/https://cgit.freedesktop.org/mesa/drm/tree/README.rst|archive-date=2020-03-21}}</ref> <ref name="fb doc">{{cite web|last1=Uytterhoeven|first1=Geert|title=The Frame Buffer Device|url=https://www.kernel.org/doc/Documentation/fb/framebuffer.txt|website=Kernel.org|access-date=28 January 2015}}</ref> <ref name="kms manpage">{{cite web|title=drm-kms man page|url=http://manpages.ubuntu.com/manpages/trusty/man7/drm-kms.7.html|website=Ubuntu manuals|access-date=19 November 2015}}</ref> <ref name="drm-mem manpage">{{cite web|title=drm-memory man page|url=http://manpages.ubuntu.com/manpages/trusty/man7/drm-memory.7.html|website=Ubuntu manuals|access-date=29 January 2015|quote="Many modern high-end GPUs come with their own memory managers. They even include several different caches that need to be synchronized during access. [...] . Therefore, memory management on GPUs is highly driver- and hardware-dependent."}}</ref> <!-- articles --> <ref name="Airlie 2010">{{cite web|last1=Airlie |first1=Dave |title=GPU offloading - PRIME - proof of concept |url=http://airlied.livejournal.com/71734.html |date=12 March 2010 |access-date=10 February 2015 |url-status=dead |archive-url=https://web.archive.org/web/20150210173401/http://airlied.livejournal.com/71734.html |archive-date=10 February 2015 }}</ref> <ref name="Clark Semwal 2012">{{cite web|last1=Clark|first1=Rob|last2=Semwal|first2=Sumit|title=DMA Buffer Sharing Framework: An Introduction|url=http://elinux.org/images/a/a8/DMA_Buffer_Sharing-_An_Introduction.pdf|access-date=14 May 2016}}</ref> <ref name="Corbet 2004">{{cite web|last1=Corbet|first1=Jonathan|title=Kernel Summit: Video Drivers|url=https://lwn.net/Articles/94202/|website=LWN.net|date=20 July 2004|access-date=23 November 2015}}</ref> <ref name="Corbet 2007 LCA">{{cite web|last1=Corbet|first1=Jonathan|title=LCA: Updates on the X Window System|url=https://lwn.net/Articles/218380/|website=LWN.net|date=22 January 2007|access-date=23 November 2015}}</ref> <ref name="Corbet 2007">{{cite web|last1=Corbet|first1=Jonathan|title=Memory management for graphics processors|url=https://lwn.net/Articles/257417/|website=LWN.net|date=6 November 2007|access-date=23 July 2014}}</ref> <ref name="Corbet 2008">{{cite web|last1=Corbet|first1=Jonathan|title=GEM v. TTM|url=https://lwn.net/Articles/283793/|website=LWN.net|date=28 May 2008|access-date=10 February 2015}}</ref> <ref name="Corbet 2010">{{cite web|last1=Corbet|first1=Jonathan|title=The end of user-space mode setting?|url=https://lwn.net/Articles/369706/|website=LWN.net|date=13 January 2010|access-date=20 November 2015}}</ref> <ref name="Corbet 2012 dmabuf">{{cite web|last1=Corbet|first1=Jonathan|title=DMA buffer sharing in 3.3|url=https://lwn.net/Articles/474819/|website=LWN.net|date=11 January 2012|access-date=14 May 2016}}</ref> <ref name="Corbet linux 3.12">{{cite web|last1=Corbet|first1=Jonathan|title=3.12 merge window, part 2|url=https://lwn.net/Articles/566122/|website=LWN.net|date=11 September 2013|access-date=21 July 2014}}</ref> <ref name="Corbet linux 3.17">{{cite web|last1=Corbet|first1=Jonathan|title=3.17 merge window, part 2|url=https://lwn.net/Articles/608434/|website=LWN.net|date=13 August 2014|access-date=7 October 2014}}</ref> <ref name="Corbet linux 3.19">{{cite web|last1=Corbet|first1=Jonathan|title=3.19 Merge window part 2|url=https://lwn.net/Articles/626150/|website=LWN.net|date=17 December 2014|access-date=9 February 2015}}</ref> <ref name="Corbet linux 4.2">{{cite web|last1=Corbet|first1=Jonathan|title=4.2 Merge window part 2|url=https://lwn.net/Articles/649652/|website=LWN.net|date=1 July 2015|access-date=31 August 2015}}</ref> <ref name="Corbet linux 4.4">{{cite web|last1=Corbet|first1=Jonathan|title=4.4 Merge window, part 1|url=https://lwn.net/Articles/663742/|website=LWN.net|date=11 November 2015|access-date=11 January 2016}}</ref> <ref name="Corbet linux 4.5">{{cite web|last1=Corbet|first1=Jonathan|title=4.5 merge window part 2|url=https://lwn.net/Articles/672344/|website=LWN.Net|date=20 January 2016|access-date=14 March 2016}}</ref> <ref name="DRI Wiki modesetting">{{cite web|title=DrmModesetting - Enhancing kernel graphics|url=http://dri.freedesktop.org/wiki/DrmModesetting/|website=DRI Wiki|access-date=23 November 2015}}</ref> <ref name="DRI2 spec">{{cite web|last1=Høgsberg|first1=Kristian|title=The DRI2 Extension - Version 2.0|url=http://www.x.org/releases/X11R7.5/doc/dri2proto/dri2proto.txt|website=X.Org|date=4 September 2008|access-date=23 May 2016}}</ref> <ref name="Deucher 2010">{{cite web|last1=Deucher |first1=Alex |title=Notes about radeon display hardware |url=http://www.botchco.com/agd5f/?p=51 |date=15 April 2010 |access-date=8 April 2016 |url-status=dead |archive-url=https://web.archive.org/web/20160405145025/http://www.botchco.com/agd5f/?p=51 |archive-date=5 April 2016 }}</ref> <ref name="Edge 2013">{{cite web|last1=Edge|first1=Jake|title=DRI3 and Present|url=https://lwn.net/Articles/569701/|website=LWN.net|date=9 October 2013|access-date=28 May 2016}}</ref> <ref name="Edge freedreno">{{cite web|last1=Edge|first1=Jake|title=An update on the freedreno graphics driver|url=https://lwn.net/Articles/638908/|website=LWN.net|date=8 April 2015|access-date=23 April 2015}}</ref> <ref name="Faith 1999">{{cite web|last1=Faith|first1=Rickard E.|title=The Direct Rendering Manager: Kernel Support for the Direct Rendering Infrastructure|url=http://dri.sourceforge.net/doc/drm_low_level.html|date=11 May 1999|access-date=12 May 2016|archive-date=24 May 2016|archive-url=https://web.archive.org/web/20160524202114/http://dri.sourceforge.net/doc/drm_low_level.html|url-status=dead}}</ref> <ref name="Fedora KMS">{{cite web|title=Fedora - Features/KernelModeSetting|url=https://fedoraproject.org/wiki/Features/KernelModesetting|website=Fedora Project|access-date=20 November 2015|quote="Historically, the X server was responsible for saving output state when it started up, and then restoring it when it switched back to text mode. Fast user switching was accomplished with a VT switch, so switching away from the first user's X server would blink once to go to text mode, then immediately blink again to go to the second user's session."}}</ref> <ref name="Gettys Packard 2004">{{cite web|last1=Gettys|first1=James|last2=Packard|first2=Keith|title=The (Re)Architecture of the X Window System|url=http://keithp.com/~keithp/talks/xarch_ols2004/xarch-ols2004-html/|date=15 June 2004|access-date=30 April 2016}}</ref> <ref name="Glisse 2007">{{cite web|last1=Glisse|first1=Jerome|title=Radeon kernel modesetting|url=http://jglisse.livejournal.com/852.html|access-date=30 April 2016|date=4 December 2007}}</ref> <ref name="Herrmann 2012 kmscon">{{cite web|last1=Herrmann|first1=David|title=KMSCON Introduction|url=http://dvdhrm.wordpress.com/2012/12/10/kmscon-introduction/|date=10 December 2012|access-date=22 November 2015}}</ref> <ref name="Herrmann 2013 rendernodes">{{cite web|last1=Herrmann|first1=David|title=DRM Render- and Modeset-Nodes|url=http://dvdhrm.wordpress.com/2013/05/29/drm-render-and-modeset-nodes/|date=29 May 2013|access-date=21 July 2014}}</ref> <ref name="Herrmann 2013 DRM split">{{cite web|last1=Herrmann|first1=David|title=Splitting DRM and KMS device nodes|url=http://dvdhrm.wordpress.com/2013/09/01/splitting-drm-and-kms-device-nodes/|date=1 September 2013|access-date=23 July 2014}}</ref> <ref name="Herrmann 2013 XDC">{{cite web|last1=Herrmann|first1=David|title=DRM Security|url=http://www.x.org/wiki/Events/XDC2013/XDC2013DavidHerrmannDRMSecurity/DRM_SECURITY|website=The 2013 X.Org Developer's Conference (XDC2013) Proceedings|date=2 July 2013|access-date=13 February 2015|quote=gem-flink doesn't provide any private namespaces to applications and servers. Instead, only one global namespace is provided per DRM node. Malicious authenticated applications can attack other clients via brute-force "name-guessing" of gem buffers}}</ref> <ref name="Kernelnewbies linux 2.6.28">{{cite web|title=Linux 2.6.28 - The GEM Memory Manager for GPU memory|url=http://kernelnewbies.org/Linux_2_6_28#head-b957b19f6139b6bbbfabaf790bf643b1746985d6|website=Linux Kernel Newbies|access-date=23 July 2014}}</ref> <ref name="Kernelnewbies linux 2.6.29">{{cite web|title=Linux 2.6.29 - Kernel Modesetting|url=http://kernelnewbies.org/Linux_2_6_29#head-e1bab8dc862e3b477cc38d87e8ddc779a66509d1|website=Linux Kernel Newbies|access-date=19 November 2015}}</ref> <ref name="Kernelnewbies linux 2.6.31">{{cite web|title=Linux 2.6.31 - ATI Radeon Kernel Mode Setting support|url=http://kernelnewbies.org/Linux_2_6_31#head-78158343fc06e5e289f2ccaf51d6a30090a46524|website=Linux Kernel Newbies|access-date=28 April 2016|archive-url=https://web.archive.org/web/20151105025721/http://kernelnewbies.org/Linux_2_6_31#head-78158343fc06e5e289f2ccaf51d6a30090a46524|archive-date=5 November 2015|url-status=dead}}</ref> <ref name="Kernelnewbies nouveau">{{cite web|title=Linux 2.6.33 - Nouveau, a driver for Nvidia graphic cards|url=http://kernelnewbies.org/Linux_2_6_33#head-ef4ca9ac1fa7bdec15f40718c2cf216b4f3c9472|website=Linux Kernel Newbies|access-date=26 April 2016}}</ref> <ref name="Kernelnewbies linux 2.6.33">{{cite web|title=Linux 2.6.33 - Graphic improvements|url=http://kernelnewbies.org/Linux_2_6_33#head-7b9aa9665c31092b57f38ae4ee0c3627172cdf1b|website=Linux Kernel Newbies|access-date=28 April 2016}}</ref> <ref name="Kernelnewbies linux 2.6.38">{{cite web|title=Linux 2.6.38 - Graphics|url=http://kernelnewbies.org/Linux_2_6_38-DriversArch#head-647f92e38d919f452ea858999f3ece9ccc6f46df|website=Linux Kernel Newbies|access-date=28 April 2016}}</ref> <ref name="Kernelnewbies linux 2.6.39">{{cite web|title=Linux 2 6 39-DriversArch|url=http://kernelnewbies.org/Linux_2_6_39-DriversArch#head-94ecdcc82ca5e98eb1d56c20c0ef1a1274737078|website=Linux Kernel Newbies|access-date=19 April 2016}}</ref> <ref name="Kernelnewbies gma500">{{cite web|title=Linux 3.3 - DriverArch - Graphics|url=http://kernelnewbies.org/Linux_3.3_DriverArch#head-55c126b70d6e61f4496629a7f19a3be36d1ea84a|website=Linux Kernel Newbies|access-date=3 March 2016}}</ref> <ref name="Kernelnewbies linux 3.4">{{cite web|title=Linux 3.4 DriverArch|url=http://kernelnewbies.org/Linux_3.4_DriverArch|website=Linux Kernel Newbies|access-date=15 April 2016}}</ref> <ref name="Kernelnewbies linux 3.5">{{cite web|title=Linux 3.5 DriverArch|url=http://kernelnewbies.org/Linux_3.5_DriverArch|website=Linux Kernel Newbies|access-date=15 April 2016}}</ref> <ref name="Kernelnewbies linux 4.0">{{cite web|title=Linux 4.0 - DriverArch - Graphics|url=http://kernelnewbies.org/Linux_4.0-DriversArch#head-bd65a3376f9359d60c2230cfc06625a9849139bb|website=Linux Kernel Newbies|access-date=3 May 2016}}</ref> <ref name="Kernelnewbies linux 4.2">{{cite web|title=Linux 4.2 - Atomic modesetting API enabled by default|url=http://kernelnewbies.org/Linux_4.2#head-a3780edb904ea47c235cd6a4b226539228d50e17|website=Linux Kernel Newbies|access-date=3 May 2016}}</ref> <ref name="Kernelnewbies etnaviv">{{cite web|title=Linux 4.5-DriversArch - Graphics|url=http://kernelnewbies.org/Linux_4.5-DriversArch#head-bf8f7e938057931a7faa7e22547a108c01aba222|website=Linux Kernel Newbies|access-date=14 March 2016}}</ref> <ref name="Kerrisk 2012">{{cite web|last1=Kerrisk|first1=Michael|title=XDC2012: Graphics stack security|url=https://lwn.net/Articles/517375/|website=LWN.net|date=25 September 2012|access-date=25 November 2015}}</ref> <ref name="Kitching 2012">{{cite web|last1=Kitching|first1=Simon|title=DRM and KMS kernel modules|url=http://moi.vonos.net/linux/drm-and-kms/|access-date=13 May 2016}}</ref> <ref name="Larabel 2008 gem-ttm">{{cite web|last1=Larabel|first1=Michael|title=A GEM-ified TTM Manager For Radeon|url=https://www.phoronix.com/scan.php?page=news_item&px=NjY3Ng|website=Phoronix|date=26 August 2008|access-date=24 April 2016}}</ref> <ref name="Larabel 2008 KMS">{{cite web|last1=Larabel|first1=Michael|title=The State of Kernel Mode-Setting|url=https://www.phoronix.com/scan.php?page=article&item=xorg_kms_2008&num=1|website=Phoronix|date=1 October 2008|access-date=30 April 2016}}</ref> <ref name="Larabel msm">{{cite web|last1=Larabel|first1=Michael|title=Snapdragon DRM/KMS Driver Merged For Linux 3.12|url=https://www.phoronix.com/scan.php?page=news_item&px=MTQ0NzQ|website=Phoronix|date=28 August 2013|access-date=26 January 2015}}</ref> <ref name="Larabel linux 3.3">{{cite web|last1=Larabel|first1=Michael|title=The Linux 3.3 DRM Pull Is Heavy On Enhancements|url=https://www.phoronix.com/scan.php?page=news_item&px=MTA0MDk|website=Phoronix|date=10 January 2012|access-date=3 March 2016}}</ref> <ref name="Larabel 2010 PRIME">{{cite web|last1=Larabel|first1=Michael|title=Proof Of Concept: Open-Source Multi-GPU Rendering!|url=https://www.phoronix.com/scan.php?page=news_item&px=ODA1OQ|website=Phoronix|access-date=14 April 2016}}</ref> <ref name="Larabel 2012 PRIME">{{cite web|last1=Larabel|first1=Michael|title=DRM Base PRIME Support Part Of VGEM Work|url=https://www.phoronix.com/scan.php?page=news_item&px=MTA2MTM|website=Phoronix|access-date=14 April 2016|date=23 February 2012}}</ref> <ref name="Larabel 2012 PRIME 3.4">{{cite web|last1=Larabel|first1=Michael|title=Last Minute For Linux 3.4: DMA-BUF PRIME Support|url=https://www.phoronix.com/scan.php?page=news_item&px=MTA3OTQ|website=Phoronix|access-date=15 April 2016|date=30 March 2012}}</ref> <ref name="Larabel 2012 PRIME 3.5">{{cite web|last1=Larabel|first1=Michael|title=DMA-BUF PRIME Coming Together For Linux 3.5|url=https://www.phoronix.com/scan.php?page=news_item&px=MTEwMjA|website=Phoronix|access-date=15 April 2016|date=12 May 2012}}</ref> <ref name="Larabel 2014 planes">{{cite web|last1=Larabel|first1=Michael|title=Universal Plane Support Set For Linux 3.15|url=https://www.phoronix.com/scan.php?page=news_item&px=MTY1MTg|website=Phoronix|access-date=14 April 2016|date=2 April 2014}}</ref> <ref name="Larabel sti">{{cite web|last1=Larabel|first1=Michael|title=Linux 3.17 DRM Pull Brings New Graphics Driver|url=https://www.phoronix.com/scan.php?page=news_item&px=MTc1NzY|website=Phoronix|date=8 August 2014|access-date=3 March 2016}}</ref> <ref name="Larabel linux 4.2">{{cite web|last1=Larabel|first1=Michael|title=Linux 4.2 DRM Updates: Lots Of AMD Attention, No Nouveau Driver Changes|url=https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.2-Kernel-DRM|website=Phoronix|date=25 June 2015|access-date=31 August 2015}}</ref> <ref name="Larabel linux 4.4">{{cite web|last1=Larabel|first1=Michael|title=A Look At The New Features Of The Linux 4.4 Kernel|url=https://www.phoronix.com/scan.php?page=article&item=linux-44-features&num=1|website=Phoronix|date=15 November 2015|access-date=11 January 2016}}</ref> <ref name="Larabel linux 4.5">{{cite web|last1=Larabel|first1=Michael|title=The Many New Features & Improvements Of The Linux 4.5 Kernel|url=https://www.phoronix.com/scan.php?page=article&item=linux-45-features&num=1|website=Phoronix|date=24 January 2016|access-date=14 March 2016}}</ref> <ref name="Paalanen 2014">{{cite web|last1=Paalanen|first1=Pekka|title=From pre-history to beyond the global thermonuclear war|url=http://ppaalanen.blogspot.de/2014/06/from-pre-history-to-beyond-global.html|date=5 June 2014|access-date=29 July 2014}}</ref> <ref name="Packard 2007">{{cite web|last1=Packard|first1=Keith|title=kernel-mode-drivers|url=http://keithp.com/blogs/kernel-mode-drivers/|date=16 September 2007|access-date=30 April 2016}}</ref> <ref name="Packard Anholt 2008">{{cite web|last1=Packard|first1=Keith|last2=Anholt|first2=Eric|title=GEM - the Graphics Execution Manager|url=https://lwn.net/Articles/283798/|work=dri-devel mailing list|date=13 May 2008|access-date=23 July 2014}}</ref> <ref name="Packard 2008 GEM">{{cite web|last1=Packard|first1=Keith|title=gem update|url=http://keithp.com/blogs/gem_update/|date=4 July 2008|access-date=25 April 2016}}</ref> <ref name="Packard 2008 status">{{cite web|last1=Packard|first1=Keith|title=X output status july 2008|url=http://keithp.com/blogs/X_output_status_july_2008/|date=21 July 2008|access-date=1 May 2016}}</ref> <ref name="Packard 2009">{{cite web|last1=Packard|first1=Keith|title=Sharpening the Intel Driver Focus|url=http://keithp.com/blogs/Sharpening_the_Intel_Driver_Focus/|date=24 April 2000|access-date=23 May 2016|quote=A more subtle limitation is that the driver couldn't handle interrupts, so there wasn't any hot-plug monitor support.}}</ref> <ref name="Packard 2012">{{cite web|last1=Packard|first1=Keith|title=Thoughts about DRI.Next|url=http://keithp.com/blogs/DRI-Next/|date=28 September 2012|access-date=26 May 2016|quote="GEM flink has lots of issues. The flink names are global, allowing anyone with access to the device to access the flink data contents."}}</ref> <ref name="Peres Ravier 2013">{{cite web|last1=Peres|first1=Martin|last2=Ravier|first2=Timothée|title=DRI-next/DRM2: A walkthrough the Linux Graphics stack and its security|url=http://phd.mupuf.org/files/fosdem2013_drinext_drm2.pdf|date=2 February 2013|access-date=13 May 2016}}</ref> <ref name="Peres 2014">{{cite web|last1=Peres|first1=Martin|title=The Linux graphics stack, Optimus and the Nouveau driver|url=http://phd.mupuf.org/files/kr2014.pdf|date=26 September 2014|access-date=14 May 2016}}</ref> <ref name="Pinchart 2013">{{cite web|last1=Pinchart|first1=Laurent|title=Anatomy of an Embedded KMS Driver|url=http://elinux.org/images/0/0f/Elc2013_Pinchart.pdf|date=20 February 2013|access-date=27 June 2016}}</ref> <ref name="Rathmann 2008">{{cite web|last1=Rathmann|first1=B.|title=The state of Nouveau, part I|url=https://lwn.net/Articles/269558/|website=LWN.net|date=15 February 2008|access-date=23 November 2015|quote="Graphics cards are programmed in numerous ways, but most initialization and mode setting is done via memory-mapped IO. This is just a set of registers accessible to the CPU via its standard memory address space. The registers in this address space are split up into ranges dealing with various features of the graphics card such as mode setup, output control, or clock configuration."}}</ref> <ref name="Reding 2015">{{cite web|last1=Reding|first1=Thierry|title=Atomic Mode-Setting|url=https://archive.fosdem.org/2015/schedule/event/kms_atomic/attachments/slides/740/export/events/attachments/kms_atomic/slides/740/atomic_modesetting.pdf|website=FOSDEM Archives|access-date=7 May 2016|date=1 February 2015}}</ref> <ref name="Smirl 2005">{{cite web|last1=Smirl|first1=Jon|title=The State of Linux Graphics|url=https://sites.google.com/site/jonsmirl/graphics|date=30 August 2005|access-date=30 April 2016|quote=I believe the best solution to this problem is for the kernel to provide a single, comprehensive device driver for each piece of video hardware. This means that conflicting drivers like fbdev and DRM must be merged into a cooperating system. It also means that poking hardware from user space while a kernel based device driver is loaded should be prevented.}}</ref> <ref name="Verhaegen 2006">{{cite web|last1=Verhaegen|first1=Luc|title=X and Modesetting: Atrophy illustrated|url=https://people.freedesktop.org/~libv/X_and_Modesetting_-_Atrophy_illustrated_%28paper%29.pdf|access-date=30 April 2016|date=2 March 2006}}</ref> <ref name="Vetter 2011">{{cite web|last1=Vetter|first1=Daniel|title=GEM Overview|url=http://blog.ffwll.ch/2011/05/gem-overview.html|date=4 May 2011|access-date=13 February 2015}}</ref> <ref name="Vetter 2012">{{cite web|last1=Vetter|first1=Daniel|title=i915/GEM Crashcourse by Daniel Vetter|url=https://01.org/linuxgraphics/blogs/vivijim/2012/i915/gem-crashcourse-daniel-vetter|website=Intel Open Source Technology Center|access-date=31 January 2015|quote="GEM essentially deals with graphics buffer objects (which can contain textures, renderbuffers, shaders, or all kinds of other state objects and data used by the gpu)"}}</ref> <ref name="Vetter linux 3.17">{{cite web|last1=Vetter|first1=Daniel|title=Neat stuff for 3.17|url=http://blog.ffwll.ch/2014/08/neat-stuff-for-317.html|date=7 August 2014|access-date=14 April 2016}}</ref> <ref name="Vetter 2014 atomic">{{cite web|last1=Vetter|first1=Daniel|title=Atomic Modeset Support for KMS Drivers|url=http://blog.ffwll.ch/2014/11/atomic-modeset-support-for-kms-drivers.html|date=2 November 2014|access-date=4 May 2016}}</ref> <ref name="Vetter 2015 atomic">{{cite web|last1=Vetter|first1=Daniel|title=Update for Atomic Display Updates|url=http://blog.ffwll.ch/2015/01/update-for-atomic-display-updates.html|date=28 January 2015|access-date=4 May 2016}}</ref> <ref name="Vetter 2015 LWN p1">{{cite web|last1=Vetter|first1=Daniel|title=Atomic mode setting design overview, part 1|url=https://lwn.net/Articles/653071/|website=LWN.net|date=5 August 2015|access-date=7 May 2016}}</ref> <ref name="Vetter 2015 LWN p2">{{cite web|last1=Vetter|first1=Daniel|title=Atomic mode setting design overview, part 2|url=https://lwn.net/Articles/653466/|website=LWN.net|date=12 August 2015|access-date=7 May 2016}}</ref> <ref name="Vetter 2016 atomic">{{cite web|last1=Vetter|first1=Daniel|title=Embrace the Atomic Display Age|url=https://people.freedesktop.org/~danvet/presentations/lca-2016.pdf|date=3 February 2016|access-date=4 May 2016}}</ref> <ref name="Vetter 2016 atomic update">{{cite web|last1=Vetter|first1=Daniel|title=Awesome Atomic Advances|url=http://blog.ffwll.ch/2016/06/awesome-atomic-advances.html|date=6 June 2016|access-date=7 June 2016|quote=right now there's 17 drivers supporting atomic modesetting merged into the DRM subsystem}}</ref> <ref name="Stone 2018">{{cite web|last1=Stone|first1=Daniel|title=A new era for Linux's low-level graphics - Part 1|url=https://www.collabora.com/news-and-blog/blog/2018/03/20/a-new-era-for-linux-low-level-graphics-part-1/|date=20 March 2018|access-date=5 May 2018}}</ref> <ref name="White">{{cite web|last1=White|first1=Thomas|title=How DRI and DRM Work|url=http://www.bitwiz.org.uk/s/how-dri-and-drm-work.html|access-date=22 July 2014}}</ref> <!-- Mailing lists messages --> <ref name="Airlie redesign">{{cite mailing list|mailing-list=dri-devel|last=Airlie|first=Dave|title=New proposed DRM interface design|date=4 September 2004|url=https://lwn.net/Articles/100839/}}</ref> <ref name="Airlie DRM split">{{cite mailing list|mailing-list=linux-kernel|last=Airlie|first=Dave|title=[bk pull] drm core/personality split|date=30 December 2004|url=https://lwn.net/Articles/117419/}}</ref> <ref name="Torvalds linux 2.6.11-rc1">{{cite mailing list|mailing-list=linux-kernel|last=Torvalds|first=Linus|author-link=Linus Torvalds|title=Linux 2.6.11-rc1|date=11 January 2005|url=https://lkml.org/lkml/2005/1/12/6}}</ref> <ref name="Barnes modesetting">{{cite mailing list|mailing-list=linux-kernel|last=Barnes|first=Jesse|title=[RFC] enhancing the kernel's graphics subsystem|date=17 May 2007|url=https://lwn.net/Articles/235120/}}</ref> <ref name="xf86-video-intel 2.5.0">{{cite mailing list|mailing-list=xorg-announce|title=[ANNOUNCE] xf86-video-intel 2.5.0|first=Jesse|last=Barnes|date=20 October 2008|url=https://lists.freedesktop.org/archives/xorg-announce/2008-October/000677.html}}</ref> <ref name="Torvalds linux 2.6.31">{{cite mailing list|mailing-list=linux-kernel|title=Linux 2.6.31|last=Torvalds|first=Linus|author-link=Linus Torvalds|date=9 September 2009|url=http://lkml.iu.edu/hypermail/linux/kernel/0909.1/00839.html}}</ref> <ref name="Barnes 2011 overlays">{{cite mailing list|mailing-list=dri-devel|last=Barnes|first=Jesse|title=[RFC] drm: add overlays as first class KMS objects|date=25 April 2011|url=https://lists.freedesktop.org/archives/dri-devel/2011-April/010559.html}}</ref> <ref name="Barnes 2011 planes">{{cite mailing list|mailing-list=dri-devel|last=Barnes|first=Jesse|title=[RFC] drm: add overlays as first class KMS objects|date=13 May 2011|url=https://lists.freedesktop.org/archives/dri-devel/2011-May/011178.html}}</ref> <ref name="Barnes atomic">{{cite mailing list|mailing-list=dri-devel|last=Barnes|first=Jesse|title=[RFC] drm: atomic mode set API|date=15 February 2012|url=https://lists.freedesktop.org/archives/dri-devel/2012-February/019165.html}}</ref> <ref name="Syrjala 2012 atomic">{{cite mailing list|mailing-list=dri-devel|last=Syrjälä|first=Ville|title=[RFC][PATCH 0/6] WIP: drm: Atomic mode setting idea|date=24 May 2012|url=https://lists.freedesktop.org/archives/dri-devel/2012-May/023398.html}}</ref> <ref name="Clark 2012 atomic">{{cite mailing list|mailing-list=dri-devel|last=Clark|first=Rob|title=[RFC 0/9] nuclear pageflip|date=9 September 2012|url=https://lists.freedesktop.org/archives/dri-devel/2012-September/027506.html}}</ref> <ref name="Airlie PRIME patch">{{cite mailing list|mailing-list=dri-devel|last=Airlie|first=Dave|title=[PATCH] drm: base prime/dma-buf support (v5)|date=27 March 2012|url=https://lists.freedesktop.org/archives/dri-devel/2012-March/020611.html}}</ref> <ref name="Russell armada">{{cite mailing list|mailing-list=dri-devel|last=King|first=Russell|title=[GIT PULL] Armada DRM support|date=18 October 2013|url=http://lists.freedesktop.org/archives/dri-devel/2013-October/047640.html}}</ref> <ref name="Clark 2013 atomic">{{cite mailing list|mailing-list=dri-devel|last=Clark|first=Rob|title=[RFCv1 00/12] Atomic/nuclear modeset/pageflip|date=6 October 2013|url=https://lists.freedesktop.org/archives/dri-devel/2013-October/046618.html}}</ref> <ref name="Roper 2014">{{cite mailing list|mailing-list=dri-devel|last=Roper|first=Matt|title=[RFCv2 00/10] Universal plane support|date=7 March 2014|url=http://lists.freedesktop.org/archives/dri-devel/2014-March/055222.html}}</ref> <ref name="Airlie linux 3.19">{{cite mailing list|mailing-list=dri-devel|last=Airlie|first=Dave|title=[git pull] drm for 3.19-rc1|date=14 December 2014|url=https://lists.freedesktop.org/archives/dri-devel/2014-December/073956.html}}</ref> <ref name="Airlie linux 4.0">{{cite mailing list|mailing-list=dri-devel|last=Airlie|first=Dave|title=[git pull] drm pull for 3.20-rc1|date=15 February 2015|url=https://lists.freedesktop.org/archives/dri-devel/2015-February/077595.html}}</ref> <ref name="Deucher amdgpu">{{cite mailing list|mailing-list=dri-devel|last=Deucher|first=Alex|title=Initial amdgpu driver release|date=20 April 2015|url=http://lists.freedesktop.org/archives/dri-devel/2015-April/081501.html}}</ref> <ref name="Deucher amdgpu fiji">{{cite mailing list|mailing-list=dri-devel|last=Deucher|first=Alex|title=[PATCH 00/11] Add Fiji Support|date=3 August 2015|url=http://lists.freedesktop.org/archives/dri-devel/2015-August/087587.html}}</ref> <ref name="Airlie linux 4.7">{{cite mailing list|mailing-list=dri-devel|last=Airlie|first=Dave|title=[git pull] drm for v4.7|date=23 May 2016|url=https://lists.freedesktop.org/archives/dri-devel/2016-May/108049.html}}</ref> <ref name="libdrm 2.4.3">{{cite mailing list|mailing-list=dri-devel|last=Anholt|first=Eric|title=[ANNOUNCE] libdrm-2.4.3|date=22 December 2008|url=https://lists.x.org/archives/xorg-announce/2008-December/000735.html}}</ref> <ref name="libdrm 2.4.17">{{cite mailing list|mailing-list=dri-devel|last=Airlie|first=Dave|title=[ANNOUNCE] libdrm 2.4.17|date=21 December 2009|url=http://marc.info/?l=dri-devel&m=126137228704400}}</ref> <ref name="libdrm 2.4.25">{{cite mailing list|mailing-list=dri-devel|last=Wilson|first=Chris|title=[ANNOUNCE] libdrm 2.4.25|date=11 April 2011|url=https://lists.freedesktop.org/archives/dri-devel/2011-April/010031.html}}</ref> <ref name="libdrm 2.4.34">{{cite mailing list|mailing-list=dri-devel|last=Anholt|first=Eric|title=[ANNOUNCE] libdrm 2.4.34|date=10 May 2012|url=https://lists.freedesktop.org/archives/xorg-announce/2012-May/001948.html}}</ref> <ref name="libdrm 2.4.36">{{cite mailing list|mailing-list=xorg-announce|last=Widawsky|first=Ben|title=[ANNOUNCE] libdrm 2.4.36|date=27 June 2012|url=https://lists.x.org/archives/xorg-announce/2012-June/001984.html}}</ref> <ref name="libdrm 2.4.55">{{cite mailing list|mailing-list=dri-devel|last=Lankhorst|first=Maarten|title=[ANNOUNCE] libdrm 2.4.55|date=25 July 2014|url=https://lists.freedesktop.org/archives/dri-devel/2014-July/064703.html}}</ref> <ref name="libdrm 2.4.62">{{cite mailing list|mailing-list=dri-devel|last=Velikov|first=Emil|title=[ANNOUNCE] libdrm 2.4.62|date=29 June 2015|url=https://lists.freedesktop.org/archives/dri-devel/2015-June/085375.html}}</ref> <!-- git commits --> <ref name="nouveau merge">{{cite web|title=drm/nouveau: Add DRM driver for NVIDIA GPUs|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6ee738610f41b59733f63718f0bdbcba7d3a3f12|website=Kernel.org|access-date=27 January 2015}}</ref> <ref name="exynos merge">{{cite web|title=DRM: add DRM Driver for Samsung SoC EXYNOS4210.|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1c248b7d2960faec3e1b8f3f9c5d9d0df28e0a3c|website=Kernel.org|access-date=3 March 2016}}</ref> <ref name="vmwgfx merge">{{cite web|title=vmwgfx: Take the driver out of staging|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5a7b74beca675968f612ad6188808ed67ac58e36|website=Kernel.org|access-date=3 March 2016}}</ref> <ref name="ast merge">{{cite web|title=drm: Initial KMS driver for AST (ASpeed Technologies) 2000 series (v2)|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=312fec1405dd546ddb3fa6387d54e78f604dd8f8|website=Kernel.org|access-date=3 March 2016}}</ref> <ref name="shmobile merge">{{cite web|title=drm: Renesas SH Mobile DRM driver|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=51c1327876f35d61c8bdd81fc96e1b501c9380ee|website=Kernel.org|access-date=3 March 2016}}</ref> <ref name="tegra merge">{{cite web|title=drm: Add NVIDIA Tegra20 support|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d8f4a9eda006788d8054b8500d9eb5b6efcd8755|website=Kernel.org|access-date=3 March 2016}}</ref> <ref name="omapdrm merge">{{cite web|title=drm/omap: move out of staging|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8bb0daffb0b8e45188066255b4203446eae181f1|website=Kernel.org|access-date=3 March 2016}}</ref> <ref name="rcar merge">{{cite web|title=drm: Renesas R-Car Display Unit DRM driver|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4bf8e1962f91eed5dbee168d2348983dda0a518f|website=Kernel.org|access-date=3 March 2016}}</ref> <ref name="msm merge">{{cite web|title=drm/msm: basic KMS driver for snapdragon|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c8afe684c95cd17cf4f273d81af369a0fdfa5a74|website=Kernel.org|access-date=3 March 2016}}</ref> <ref name="armada merge">{{cite web|title=DRM: Armada: Add Armada DRM driver|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=96f60e37dc66091bde8d5de136ff6fda09f2d799|website=Kernel.org|access-date=3 March 2016}}</ref> <ref name="bochs merge">{{cite web|title=drm/bochs: new driver|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0a6659bdc5e8221da99eebb176fd9591435e38de|website=Kernel.org|access-date=3 March 2016}}</ref> <ref name="imx merge">{{cite web|title=drm: imx: Move imx-drm driver out of staging|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6556f7f82b9c401950d703072c0d8137b6f9f516|website=Kernel.org|access-date=9 February 2015}}</ref> <ref name="rockchip merge">{{cite web|title=drm: rockchip: Add basic drm driver|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2048e3286f347db5667708e47448176b5329e8d8#diff-ed4f42f4bcd152f16e2ba81c4c5fda03|website=Kernel.org|access-date=3 March 2016}}</ref> <ref name="virtio merge">{{cite web|title=Add virtio gpu driver.|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dc5698e80cf724770283e10414054662bdf6ccfa|website=Kernel.org|access-date=3 March 2016}}</ref> <ref name="vc4 merge">{{cite web|title=drm/vc4: Add KMS support for Raspberry Pi.|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c8b75bca92cbf064b9fa125fc74a85994452e935|website=Kernel.org}}</ref> <ref name="sun4i merge">{{cite web|title=Merge tag 'sun4i-drm-for-4.7'|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d3a8f6784a9cb47c344073624491e571ff1616ec|website=Kernel.org}}</ref> <ref name="hisilicon merge">{{cite web|title=Merge tag 'drm-hisilicon-next-2016-04-29'|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=4946dd2e14d252cd04e188ed6a4b794541d1c3ce|website=Kernel.org}}</ref> <ref name="mediatek merge">{{cite web|title=Merge tag 'mediatek-drm-2016-05-09'|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2e726dc4b4e2dd3ae3fe675f9d3af88a2d593ee1|website=Kernel.org}}</ref> <ref name="gamma remove">{{cite web|title=drm: remove the gamma driver|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1fad99499afdd2730adb1d53413b91580b1f0662|website=Kernel.org|access-date=27 January 2015}}</ref> <ref name="ffb remove">{{cite web|title=[DRM]: Delete sparc64 FFB driver code that never gets built|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b82f87f6d40f944a591d8d36c0fed2d4374efcb7|website=Kernel.org|access-date=27 January 2015}}</ref> <ref name="i830 remove">{{cite web|title=drm: remove i830 driver|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7f50684717511d30bba180902105c4cd4efca732|website=Kernel.org|access-date=27 January 2015}}</ref> <ref name="unichrome merge">{{cite web|title=drm: Add via unichrome support|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=22f579c621e2f264e6d093b07d75f99bc97d5df2|website=Kernel.org|access-date=27 January 2015}}</ref> <ref name="savage merge">{{cite web|title=drm: add savage driver|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=282a16749ba63256bcdce2766817f46aaac4dc20|website=Kernel.org|access-date=27 January 2015}}</ref> <ref name="Mesa 3dfx">{{cite web|title=First DRI release of 3dfx driver.|url=http://cgit.freedesktop.org/mesa/drm/commit/?id=b6a28bfe98f2c89cfb91079bd3c7b63fb0144eb1|website=Mesa 3D|access-date=15 July 2014}}</ref> <ref name="Linux 2.3.18pre1">{{cite web|title=Import 2.3.18pre1|url=http://repo.or.cz/w/davej-history.git/commit/9af6f6e4860e86507da2d470dd6a3bee34bf58c2|website=The History of Linux in GIT Repository Format 1992-2010 (2010)|access-date=15 July 2014}}</ref> <ref name="reorganization commit">{{cite web|title=drm: reorganise drm tree to be more future proof|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c0e09200dc0813972442e550a5905a132768e56c|website=Kernel.org}}</ref> <ref name="KMS commit">{{cite web|title=DRM: add mode setting support|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f453ba0460742ad027ae0c4c7d61e62817b3e7ef|website=Kernel.org}}</ref> <ref name="KMS i915 commit">{{cite web|title=DRM: i915: add mode setting support|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=79e539453b34e35f39299a899d263b0a1f1670bd|website=Kernel.org}}</ref> <ref name="KMS radeon commit">{{cite web|title=drm/radeon: introduce kernel modesetting for radeon hardware|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=771fe6b912fca54f03e8a72eb63058b582775362|website=Kernel.org}}</ref> <ref name="TTM commit">{{cite web|title=drm: Add the TTM GPU memory manager subsystem.|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ba4e7d973dd09b66912ac4c0856add8b0703a997|website=Kernel.org}}</ref> <ref name="pageflip commit">{{cite web|title=drm/kms: add page flipping ioctl|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d91d8a3f88059d93e34ac70d059153ec69a9ffc7|website=Kernel.org}}</ref> <ref name="dumb-buffers commit">{{cite web|title=drm: dumb scanout create/mmap for intel/radeon (v3)|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ff72145badb834e8051719ea66e024784d000cb4|website=Kernel.org}}</ref> <ref name="planes commit">{{cite web|title=drm: add plane support v3|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8cf5c9177151537e73ff1816540e4ba24b174391|website=Kernel.org}}</ref> <ref name="properties commit">{{cite web|title=drm: add generic ioctls to get/set properties on any object|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c543188afb7a83e66161c026dc6fd5eb38dc0b63|website=Kernel.org}}</ref> <ref name="PRIME commit">{{cite web|title=drm: base prime/dma-buf support (v5)|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=3248877ea1796915419fba7c89315fdbf00cb56a|website=Kernel.org}}</ref> <ref name="rendernodes commit">{{cite web|title=drm: implement experimental render nodes|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1793126fcebd7c18834f95d43b55e387a8803aa8|website=Kernel.org}}</ref> <ref name="rendernodes i915">{{cite web|title=drm/i915: Support render nodes|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=10ba50129ab0bdbc0ee712e50913d1c8db88c5f0|website=Kernel.org}}</ref> <ref name="rendernodes radeon">{{cite web|title=drm/radeon: Support render nodes|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f33bcab9e816c5bf56b74c3007790f2a256910eb|website=Kernel.org}}</ref> <ref name="rendernodes nouveau">{{cite web|title=drm/nouveau: Support render nodes|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7d7612582c15af8772c2fb2473d5fc7eebfefae2|website=Kernel.org}}</ref> <!-- other --> <ref name="linux maintainers">{{cite web|title=List of maintainers of the linux kernel|url=https://www.kernel.org/doc/linux/MAINTAINERS|website=Kernel.org|access-date=14 July 2014}}</ref> <ref name="libdrm git">{{cite web|title=libdrm git repository|url=http://cgit.freedesktop.org/mesa/drm/|access-date=23 July 2014}}</ref> <ref name="Linux 2.4.0">{{cite web|last1=Torvalds|first1=Linus|title=Linux 2.4.0 source code|url=https://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.0.tar.gz|website=Kernel.org|access-date=29 July 2014}}</ref> <ref name="nouveau 40">{{cite web|title=The irregular Nouveau Development Companion #40|url=https://nouveau.freedesktop.org/wiki/Nouveau_Companion_40/|website=Nouveau project|access-date=3 May 2016}}</ref> <ref name="X wiki modesetting">{{cite web|title=Mode Setting Design Discussion|url=http://www.x.org/wiki/ModeSetting/|website=X.Org Wiki|access-date=19 November 2015}}</ref> <ref name="X wiki videocards">{{cite web|title=Video Cards|url=http://xorg.freedesktop.org/wiki/Development/Documentation/HowVideoCardsWork/|website=X.Org Wiki|access-date=11 April 2016}}</ref> <ref name="X11R6.1 relnotes">{{cite web|title=X11R6.1 Release Notes|url=http://www.x.org/wiki/X11R6.1/|website=X.Org|date=14 March 1996|access-date=23 April 2016}}</ref> <ref name="XF86vidmode man">{{cite web|title=XF86VIDMODE manual page|url=http://www.x.org/releases/X11R7.7/doc/man/man3/XF86VM.3.xhtml|website=X.Org|access-date=23 April 2016}}</ref> <ref name="OSDev VGA">{{cite web|title=VGA Hardware|url=http://wiki.osdev.org/VGA_Hardware|website=OSDev.org|access-date=23 November 2015}}</ref> <ref name="Intel UMA">{{cite web|title=Intel Graphics Media Accelerator Developer's Guide|url=https://software.intel.com/sites/default/files/ae/4e/15732|publisher=Intel Corporation|access-date=24 November 2015}}</ref> }} == External links == *[http://dri.freedesktop.org/wiki/DRM DRM home page] *[https://dri.freedesktop.org/docs/drm/gpu/ ''Linux GPU Driver Developer's Guide''] (formerly ''Linux DRM Developer's Guide'') * {{YouTube|Ja8fM7rTae4|Embedded Linux Conference 2013 - Anatomy of an Embedded KMS driver}} {{Linux kernel}} {{Freedesktop.org}} [[Category:Direct Rendering Infrastructure]] [[Category:Interfaces of the Linux kernel]] [[Category:Linux kernel features]]
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)
Pages transcluded onto the current version of this page
(
help
)
:
Template:Active
(
edit
)
Template:Anchor
(
edit
)
Template:Cite web
(
edit
)
Template:Distinguish
(
edit
)
Template:Freedesktop.org
(
edit
)
Template:Infobox
(
edit
)
Template:Infobox software
(
edit
)
Template:Linux kernel
(
edit
)
Template:Main article
(
edit
)
Template:Main other
(
edit
)
Template:Mono
(
edit
)
Template:Multiple image
(
edit
)
Template:Partial
(
edit
)
Template:Portal
(
edit
)
Template:R
(
edit
)
Template:Reflist
(
edit
)
Template:Short description
(
edit
)
Template:Template other
(
edit
)
Template:Yes
(
edit
)
Template:YouTube
(
edit
)