"Atomic Display Framework" Shown For Linux

A Google developer has released code to a new Linux kernel project: ADF, the Atomic Display Framework. This kernel framework came about as the developer was experimenting with KMS and Android.

Greg Hackmann is the Google developer responsible for this new display framework. The Atomic Display Framework came about as he was experimenting with a KMS-based hardware composer for Android. ADF is designed to take care of some shortcomings Hackmann had in dealing with the Linux kernel mode-setting code like it being designed around updating one object at a time, SoC mapping to different objects can be a challenge, there isn't support for custom pixel formats, and there isn't a way for exchanging sync fences. ADF seeks to address some of these KMS shortcomings but for now these "request for comments" patches aren't KMS-based and simply seeking feedback whether there's interest in going forth and merging this work in the future.

Greg will be talking about the Atomic Display Framework at this year's Linux Plumbers Conference for those interested. The work right now consists of four patches and can be found on dri-devel. In ending, here's the full developer description on the Atomic Display Framework.

ADF represents display devices as collections of overlay engines and interfaces. Overlay engines (struct adf_overlay_engine) scan out images and interfaces (struct adf_interface) display those images. Overlay engines and interfaces can be connected in any n-to-n configuration that the hardware supports.

Clients issue atomic updates to the screen by passing in a list of buffers (struct adf_buffer) consisting of dma-buf handles, sync fences, and basic metadata like format and size. If this involves composing multiple buffers, clients include a block of custom data describing the actual composition (scaling, z-order, blending, etc.) in a driver-specific format.

Drivers provide hooks to validate these custom data blocks and commit the new configuration to hardware. ADF handles importing the dma-bufs and fences, waiting on incoming sync fences before committing, advancing the display's sync timeline, and releasing dma-bufs once they're removed from the screen.

ADF represents pixel formats using DRM-style fourccs, and automatically sanity-checks buffer sizes when using one of the formats listed in drm_fourcc.h. Drivers can support custom fourccs if they provide hooks to validate buffers that use them.

ADF also provides driver hooks for modesetting, managing and reporting hardware events like vsync, and changing DPMS state. These are documented in struct adf_{obj,overlay_engine,interface,device}_ops, and are similar to the equivalent DRM ops.