October 26, 2016 - Chris Michael
Ecore_Drm2: How to Use Atomic Modesetting
In a previous article, I briefly discussed how the Ecore_Drm2 library came into being. This article will expand on that article and provide a brief introduction to the Atomic Modesetting and Nuclear Pageflip features inside the new Ecore_Drm2 library.
What Makes Atomic Modesetting and Nuclear Pageflip so Great?
For those that are unaware of what “modesetting” is, you may read more about it here. Atomic Modesetting is a feature that allows for output modes (resolutions, refresh rate, etc) to be tested in advance on a single screen or on multiple outputs. A benefit of this feature is that the given mode may be tested prior to being applied. If the test of a given output mode fails, the screen image doesn’t need to be changed to confirm a given mode works or not, thus reducing screen flickering.
Atomic/Nuclear Pageflipping allows for a given scanout framebuffer object and/or one or more hardware plane framebuffers to be updated in a single atomic operation. This means that updates to the screen output, whether they be updates of a given hardware plane, updates to a CRTC framebuffer, or even updates to rotation can happen in a single vblank interrupt. For the end user, this provides a much more friendly screen update by reducing redraws and flicker.
One of the things we strive to do with EFL is to keep our API simple to use. With that in mind, you will not notice any new API functions related to using Atomic Modesetting or Nuclear Pageflipping inside the Ecore_Drm2 library. You may be asking yourself right now: “Well, how do I make use of this then?” I have great news, you may already be using it :-). Rather than add new API functions, which need to be explicitly called for these features, I decided early that these benefits should come without any cost so that existing applications can make use of them without having to be modified.
The Technical Details
Inside the Ecore_Drm2 library there are various API functions that allow for setting output modes, or even sending a framebuffer object to scanout. These existing API functions have been modified to make use of Atomic Modesetting/Nuclear Pageflipping automatically where applicable. This means applications that are already using the various APIs of the Ecore_Drm2 library do not need to be changed.
Behind the scenes, the usage of Atomic Modesetting/Pageflipping is determined at runtime. This means that when the Ecore_Drm2 library gets initialized, it will make some checks to see if atomic usage is supported. Currently, these features are only supported on an Intel (i915) graphics card with a linux kernel version >= 4.8.0. If the Ecore_Drm2 initialization finds the proper driver and kernel version, it will then attempt to enable DRM_CLIENT_CAP_ATOMIC to support Atomic Modesetting/Pageflipping. If the client capability is successfully set, it will then attempt to enable DRM_CLIENT_CAP_UNIVERSAL_PLANES in order to enable hardware plane support.
Assuming all of the internal checks pass and the client capabilities are set successfully, the application will gain the added benefits of these features without any added work :-). There is one more thing that May be needed on some systems to get this working: it has been my experience that some boxes still need kernel boot-time options enabled for atomic to function. The necessary options (if required) are: drm.atomic=1, and i915.nuclear_pageflip=1.
While these features may not yet be available for all end-users to enjoy, the benefits they provide should be something that everyone can look forward to. With the continued hard work of linux kernel developers and graphics driver developers, we may all be able to enjoy these redraws soon 🙂
About Chris Michael
Chris Michael has been an EFL/Enlightenment developer for over 13 years and is now working for the Samsung Open Souce Group. Among his many ongoing projects include his work to port the Enlightenment Foundation Libraries to the Wayland protocol, porting the Tizen Window Manager to use the Wayland protocol, and writing an IRC client which will function using the Wayland protocol. He has given several talks at various LinuxCon events all around the globe, generally focused on Wayland.
Image Credits: EFL Project