Simon Ser

Wayland compositors try to make of most of the hardware by displaying directly without any copy pixel buffers coming from clients such as games, browsers and video players. This lowers battery usage, improves latency and leaves the 3D engine free for clients to use. The display engines found in modern GPUs often can support this zero-copy mechanism only if the buffers have been allocated in a special fashion. However, buffers allocated this way won't be optimal for rendering, and only a handful of buffers can be directly displayed.

As a result, a trade-off between zero-copy display and optimal rendering needs to be made. The compositor is the natural place where a decision can be made, because it has a global view of all apps which need to be presented. Once the compositor has taken a decision, it needs to be communicated to the clients. The brand new linux-dmabuf feedback protocol enables this negotiation between the compositor and the clients.

If you're up for some window system integration madness, grab some popcorn and come enjoy the show!

This talk will explain some basics about KMS, introduce libliftoff, describe the library's current status and outline the next steps.

Many DRM drivers have been exposing overlay planes for quite some time. Overlay planes can improve battery consumption by scanning out directly client buffers, skipping composition. While Wayland compositors and the X server usually take advantage of the cursor plane (and sometimes are able to use the primary plane to directly scan out a client's buffer), overlay planes are under-used. The exception is Weston, which tries to use overlay planes. Other compositors ignore them.

The main challenge is to figure out how to assign buffers coming from clients to hardware planes. The only API exposed by KMS is atomic test commits, so user-space needs to try different combinations. It would be nice to have a common library shared between compositors to de-duplicate the work.

During the XDC 2019 conference we discussed about libliftoff, an attempt at designing such a library. Feedback was positive from both compositor writers and driver developers. We discussed about the API, the potential pitfalls and future goals. The scope of the library has been expanded: libliftoff could also provide some feedback to clients so that they allocate buffers suitable for hardware planes. Additionally, because the KMS API makes it tricky to find the best way to make use of hardware planes, libliftoff could grow some vendor-specific plugins.