Linux graphical environment without a single break

TL; DR - If your Linux graphical environment while watching a video, playing a game or scrolling an interactive web page does not have time to update the entire picture in time, then it makes sense for you to install the latest stable kernel version ≥ 4.10.

A long time ago, that is, a few years ago, every implementation of the X11 protocol involved changing the video mode directly, across the kernel kernel. Then KMS (kernel mode setting) appeared and this important function passed to the kernel. But there were some rough edges. Atomic mode change is a further improvement of the KMS mechanism.

What are KMS atomic operations for? Mainly in order to avoid such moments.

Atomic video mode change

DRM driver with support for atomic mode change, a ․ k ․ a ․ Atomic mode setting has a useful feature, which is that video mode changes are fully tested before they take effect. This is done in order to ensure their correct performance in the drivers and on the display in order to save users from flickering, tearing and other image artifacts. The speed of execution also increases. It sounds good, but how does it work?

• Framebuffer - Video memory, but in KMS terminology it is rather a pool of video memory sources - GEM objects, for which such characteristics as the active memory zone, or what will be shown, as well as the data format, step length are specified.

Framebuffer

DRM/KMS Components: Framebuffer struct drm_framebuffer { [...] unsigned int pitches[4]; unsigned int offsets[4]; unsigned int width; unsigned int height; int flags; [...] 

• CRTC - Abbreviation stands for Cathode Ray Tube Controller, CRT Controller. Few people currently use monitors on cathode-ray tubes, but the historical name is preserved from the form of iron abstraction, which reads bytes from the video card's memory and sends pixels to the data bus.
• Encoder - Interface between disparate video sources, reads from CRTC and transmits to the connector, a k ․ a ․ Connector . A CRTC may have several encoders.
• Connector - This can be a view for the monitor connector or the monitor itself in the case of embedded devices with an external screen connected.
• Planes - Layer or image plan on CRTC .

To do this, you need to understand how the video mode changes without this innovation. Consider the usual scenario in which the user is watching a video in a browser or player window, not full-screen, using hardware acceleration. The video forms the foreground, window, and scenery of the browser or player; this is the second - the background.

1. A list of various parameters is transmitted to the video driver: frame buffer, CRTC, screens, mode.
2. The user moves the player window.
3. To do this, upload a new page, a ․ k ․ a ․ page flip , for example.
4. If the new page is not synchronized between the foreground and background, the video will shift relative to its window.

 struct drm_mode_crtc_page_flip { __u32 crtc_id; __u32 fb_id; __u32 flags; __u32 reserved; __u64 user_data; }; 

There is no mechanism to ensure synchronization in the penultimate step; ioctl() missing to do all the work. For example, only the basic plan had a mechanism for non-blocking updates of critical events with precise completion. And in order for the updates to occur in several layers, a lot of system calls from the user space were required in the hope that they would end synchronously . At the same time, atomic KMS operations have built-in protection against this. Instead of three different ioctl() , all changes take place in a single ioctl() .

In fact, the problem of lack of synchronization between the active zone and the background while watching a video was solved by arranging everything with GL, since the latter can update frames synchronously with VBlank. Everything would be fine, but for mobile devices this is not acceptable due to the high memory and power requirements of the GL linker.

Work on the "atomic" project began in 2015 with patches of Dave Airlie (Dave Airlie) , affecting Intel's i915 and a few more drivers, plus a new atomic API.

At the moment, the atomic update process is as follows.

1. All changes are transferred to the kernel with one property list (in the middle of the Properties image).
2. The kernel generates a device state (on the right in the State picture).
3. atomic_check() checks the validity of all items in the property list. If there is an error, ioctl () will return an error notification and cancel the update.
4. atomic_commit() also, in accordance with the name, introduces changes into action if atomic_check() completed in the previous step without errors.

The structure of the atomic KMS is defined in the /usr/include/uapi/drm/drm_mode.h file.

 #define DRM_MODE_PAGE_FLIP_EVENT 0x01 #define DRM_MODE_PAGE_FLIP_ASYNC 0x02 #define DRM_MODE_ATOMIC_TEST_ONLY 0x0100 #define DRM_MODE_ATOMIC_NONBLOCK 0x0200 #define DRM_MODE_ATOMIC_ALLOW_MODESET 0x0400 struct drm_mode_atomic { __u32 flags; __u32 count_objs; __u64 objs_ptr; __u64 count_props_ptr; __u64 props_ptr; __u64 prop_values_ptr; __u64 reserved; __u64 user_data; }; 

For open source Nouveau drivers from Nvidea, atomic KMS is enabled by default starting with Linux 4.10, for Intel drivers starting from 4.12. Further more!

Used materials

• Atomic mode setting design overview, part 1
• Atomic mode setting design overview, part 2
• Anatomy of atomic KMS driver
• Anatomy of atomic KMS driver, YouTube