The Linux Display Next Hackfest, graciously hosted by Igalia in the beautiful city of A Coruña, was an event that brought together a diverse group of individuals from various projects and companies, all with a common interest in the world of Linux graphics.
The event was a buzzing hive of discussions, with the primary focus being on Direct Rendering Manager (DRM), compositors and an array of topics related to graphics in Linux. Representatives from Fedora, Mutter, KWin, AMD, Nvidia, Google, and many others were present, lending their expertise and insights to the conversations.
Various subject were covered:
- Color pipeline API, to represent the different color processes;
- HDR support, including how compositors can utilize certain features and how the kernel can be improved;
- Variable refresh rate, a technology that synchronizes the display’s refresh rate with the frame rate of the content, thereby eliminating screen tearing and stuttering;
- Power-saving strategies to ensure energy-efficient operation while maintaining visual quality, such as ABM on AMD or DPST on Intel;
- Robust testing methodologies to maintain high-quality standards;
- Plane support to offload work to the graphic pipeline, improving performance and efficiency, although a significant issue was how to report hardware limitations, which can depend on various factors (plane size, encoding, framerate, etc.);
- Display muxing to seamlessly switch between GPUs without disrupting the user, such as causing a blank screen;
- Display control to change various aspects of the screen: backlight, tonemapping, segmented backlight, etc.
Each of these topics was thoroughly examined and discussed, with the shared goal of pushing the boundaries of what’s possible in the Linux display ecosystem and delivering an unparalleled visual experience to users.
The notes from this event can be found here.
Variable Refresh Rate (VRR)
The frame timing discussion at the Linux Display Next Hackfest highlighted the limitations of the current user-space API (uAPI) for variable refresh rate (VRR) displays. These limitations include abrupt changes in brightness due to changes in refresh rate, flickering, and headaches. The group brainstormed potential solutions, including restricting adaptive sync to apps with a fixed update rate and smoothing refresh rate changes. However, these solutions have their own drawbacks, such as brightness changes still being visible and scheduling challenges.
The group also considered the possibility of new kernel-mode setting (KMS) APIs to improve VRR support. Some hardware vendors, such as Intel, already support “smoothing” of the frame rate natively. The group discussed the possibility of minimum and maximum refresh rate properties, as well as an API to disable kernel-side low frame rate compensation (LFC).
The consensus of the group was that a min/max VRR API and KMS guarantees for a rate in-between would be beneficial. Additionally, an API to disable LFC would be useful for cases where user-space LFC is preferred. However, the group also acknowledged the challenges of duplicating sources of truth and code paths, as well as the need for panel drivers to hardcode EDIDs in some cases.
Color pipeline
Harry Wentland proposed a new uAPI for representing the color pipeline in DRM. The main target is to be able to represent the transformations between the userspace framebuffer and the screen. Today, most of the GPU can natively do many operation: LUT transformations, curves, scaling… with this API the userspace will be able to render exactly the same on every computer.
The proposal exposes to userspace the color path as a list of “color ops”. Those ops have to be well defined, the maint point is to be able to use this generic API to get the exact same result if the color ops are exactly the same.
Today most of this is done in userspace, and offloaded to gpu shaders, but with the help of this API, it will reduce the load on the GPU.
Testing
The discussion then moved to the testing of video features. People expressed the desire to test two types of things: userspace behavior and driver-related issues.
I took the opportunity to introduce two projects I am currently working on: VKMS and Chamelium.
VKMS, or Virtual Kernel Mode Setting, is a tool that facilitates complete emulation of the graphics pipeline. This capability enables the verification of user-space functionality and accuracy. In the coming months, I will focus on incorporating a ConfigFS interface, a multi-stream transport emulation, and Variable Refresh Rate.
Chamelium, a proprietary solution from Google, is primarily utilized for testing Chromebooks. It emulates physical screens and has recently been updated to include support for MST (Multi-Stream Transport). This board allows for the testing of lower-level components such as hardware and drivers.
Conclusion
In conclusion, the Linux Display Next Hackfest was a success, with many ideas shared and a multitude of topics discussed, resulting in the avoidance of countless emails. It was an honor to be invited to this event, and I eagerly anticipate the opportunity to participate in the next edition.