Editing Direct Rendering Manager (section)

==== {{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}}