This year, the Linux Display Next Hackfest was hosted by AMD in Toronto. The event brought together a diverse group of contributors from a wide range of projects and companies, all united by a shared interest in advancing Linux Graphics. Participants included kernel developers, compositor maintainers, hardware vendors, and others deeply involved in the graphics stack. For the second year in a row, I had the opportunity to attend in person—an important step for Bootlin, as staying closely engaged with the latest developments in the Linux Graphics Stack is key to delivering upstream-friendly, cutting-edge support for our customers.
As usual, a wide range of topics were discussed: commit failure feedback, backlight API, adaptive backlight management, testing, pageflip, scheduling, variable refresh rate (VRR), atomic commits, and others. What made this edition especially noteworthy was the presence of two color experts: a full day was dedicated to exploring HDR—what it is, how it works, and how we can support it properly in Linux.
You can read the notes for this event on Harry’s blog, or from Xaver Hugl, more will probably be posted later by other participants.
Commit failure feedback
One of the first topic discussed was about a limitation of an existing KMS API: commit. This syscall is very interesting because it allows synchronizing multiple changes of the display configuration (buffers, plane, CRTC, connector configurations…), but some of them might not succeed. For example, the display pipeline may only be able to display two 4k displays, but if you request three, the only feedback you have is “-EINVAL”, not very verbose and helpful to solve the issue.
This is an issue for compositors, because currently, the only way to find what is the problem is to try random configurations until it works… The request from compositor developers was basically “anything will be better than the current situation”.
Luckily, there was one unused field in the atomic commit structure, so after long discussions, it was decided to start implementing a basic, but already helpful feedback:
- add an enumeration to programatically show what is the issue: connector bandwidth, memory domain issue, API violation…
- add a debug string to help debugging (this one should not be used by your program, only to debug!)
- and maybe later: add an array of object ids to help userspace fixing the issue (which connector, buffers…)
All of this will help a lot compositors, and will avoid long screen freeze when an external display is plugged for example.
Backlight API
The current backlight control is very chaotic: there is no way to properly identify which backlight correspond to which screen, you need root permission, there is no way to synchronize the backlight change with a commit, minimum brightness is not defined (0 can be “screen powered off” or “screen very dark”, what a “32” backlight value means … depends on the driver), sometimes the driver may do some animation, etc.
All of this make this API very difficult to use from userspace, and especially by compositors. One proposal was to add a backlight property directly in the connector object. This new property would be better specified and will be accompanied by more details, like min/max values and information about actual luminance. Having a property also allows to change the backlight during an atomic commit, which will help a lot to do “HDR on SDR screens”
Display Testing
We covered three big topics around display testing: power consumption, KMS testing and compositor testing.
The power consumption testing was an interesting topic: how can we measure the actual battery life and have realistic comparison between laptops/desktop environments? The goal is to have a kind of WLTP for laptops, but even after discussing a long time, we did not find a proper way to have a common API for compositors and expose all the required options (open window, click emulation…). Some projects exists, like way-essay, wlcs, but none of them are appealing: licensing issue, complex code base, abandoned projects…
For KMS testing, we discussed about DRM CI, an on-going effort to run tests on the kernel using different physical hardware platforms. The main test suite used is IGT, this suite covers a lot of low level features, KMS API, but also hardware specific features. But it lacks on “real use-case testing”: most of the IGT tests are very atomic (testing plane rotation, testing color conversion…) and may not cover all the corner cases encountered by userspace (for example using HDMI connector, a cursor plane, and YUV crashes the driver).
As the main users of the KMS API are compositors, I suggested the idea to integrate some of the compositors test in DRM CI. This way, we could have IGT to do “unit testing” and compositors to do “integration testing”. This may increase a lot the DRM CI project, so it needs to be discussed more, but this would help everyone: compositors will get more stable APIs and kernel developers will get a more diverse set of real usage tests.
The last subject, and probably the most important one for me, was presenting the on-going VKMS ConfigFS work. Thanks to José Exposito and Google, I was able to work a lot on the implementation, and we reached a state where we can configure a lot of things in VKMS:
- dynamically create display pipeline
- configure planes, their formats, their rotations…
- configure connectors, create them dynamically to emulate MST, change their type (and I even had the time to draft HDR and graphic pipeline configuration!)…
The feedback on these features was amazing! Compositors want to integrate this to test and exercise their KMS usage. As Mutter already had some VKMS tests, it was easy to integrate VKMS in the loop, as you can see here. Both Cosmic and KWin also want to integrate it in their CI, to complete their existing tests. After the hackfest, I also got feedback on the mailing list that it will be integrated by other compositors too!
With this feedback, I hope this will help bringing attention to the series and this work.
Conclusion
Just like last year, I thoroughly enjoyed participating in this event. It was a great opportunity to connect with the community, share knowledge, and learn about a wide range of topics that are highly relevant to our work. The atmosphere was excellent—well-organized, filled with engaging discussions, productive hacking sessions, and, of course, some time to unwind over a few beers!
