🎉 Clazy Now Integrates with Clang-Tidy!

I am excited to announce a major improvement to the Clazy project: Clazy now integrates seamlessly with Clang-Tidy!

🧩 One Toolchain, All the Checks

Clazy now provides a plugin (on Unix ClazyClangTidy.so) that allows all its checks to run inside clang-tidy, unifying your static analysis workflow. You no longer need to run two separate tools — just configure Clazy’s checks through clang-tidy itself.

This change needed quite a few refactorings to make the existing Clazy codebase more adaptable. In total, changes were spread out to 9 different pull requests to gradually implement the needed changes. Besides implementing the functionality, the testsuite was also adapted to ensure Clazy’s clang-tidy provides proper results.

✅ How to Use

To load the plugin:

clang-tidy -load=ClazyClangTidy.so ...

🔒 If the plugin isn’t in a standard library path, either add it to your LD_LIBRARY_PATH or provide an absolute path to the plugin file.

Unfortunately, Clang-Tidy needs to have Clazy checks enabled explicitly and does not have a concept of “levels” to group checks. While wildcards like clazy-* would also work, it enables all manual-level checks. Those have more false positives and can hurt performance.

As a helper, you can export environment variables containing the check names to concatenate the desired combination:

export CLAZY_LEVEL0=clazy-overloaded-signal,clazy-connect-by-name,clazy-connect-non-signal,clazy-qstring-comparison-to-implicit-char,clazy-wrong-qevent-cast,clazy-lambda-in-connect,clazy-lambda-unique-connection,clazy-qdatetime-utc,clazy-qgetenv,clazy-qstring-insensitive-allocation,clazy-fully-qualified-moc-types,clazy-unused-non-trivial-variable,clazy-connect-not-normalized,clazy-mutable-container-key,clazy-qenums,clazy-qmap-with-pointer-key,clazy-qstring-ref,clazy-strict-iterators,clazy-writing-to-temporary,clazy-container-anti-pattern,clazy-qcolor-from-literal,clazy-qfileinfo-exists,clazy-qstring-arg,clazy-empty-qstringliteral,clazy-qt-macros,clazy-temporary-iterator,clazy-wrong-qglobalstatic,clazy-lowercase-qml-type-name,clazy-no-module-include,clazy-use-static-qregularexpression
export CLAZY_LEVEL1=clazy-auto-unexpected-qstringbuilder,clazy-connect-3arg-lambda,clazy-const-signal-or-slot,clazy-detaching-temporary,clazy-foreach,clazy-incorrect-emit,clazy-install-event-filter,clazy-non-pod-global-static,clazy-post-event,clazy-qdeleteall,clazy-qlatin1string-non-ascii,clazy-qproperty-without-notify,clazy-qstring-left,clazy-range-loop-detach,clazy-range-loop-reference,clazy-returning-data-from-temporary,clazy-rule-of-two-soft,clazy-child-event-qobject-cast,clazy-virtual-signal,clazy-overridden-signal,clazy-qhash-namespace,clazy-skipped-base-method,clazy-readlock-detaching
export CLAZY_LEVEL2=clazy-ctor-missing-parent-argument,clazy-base-class-event,clazy-copyable-polymorphic,clazy-function-args-by-ref,clazy-function-args-by-value,clazy-global-const-char-pointer,clazy-implicit-casts,clazy-missing-qobject-macro,clazy-missing-typeinfo,clazy-old-style-connect,clazy-qstring-allocations,clazy-returning-void-expression,clazy-rule-of-three,clazy-virtual-call-ctor,clazy-static-pmf

Checks in Clang-Tidy can be disabled when prefixing them with “-“, whereas Clazy uses “no-“ prefixes. An example clang-tidy command to use all level0 checks, with overloaded-signal being disabled and the qt-keywords manual check being enabled:

clang-tidy -load=ClazyClangTidy.so \
-checks="$CLAZY_LEVEL0,-overloaded-signal,qt-keywords" \
-p my_build_dir mydir/**.cpp

In case you want to speed up linting in the project, run-clang-tidy can be used for parallel execution.

🚧✨ Limitations & Tricks

Unlike using Clazy directly, clang-tidy has its own filter mechanism to only emit warnings from files that were provided as an input. This means if a warning is emitted from a header file and not the “.cpp” file you provide as an input, Clang-Tidy will suppress it. To see those warnings -header-filter=".*" can be added to the command.

💡💬 Getting it & Feedback

The Clang-Tidy plugin is currently not released, and some additional development on various checks is happening. For trying it out, one has to compile the project from source. It is just a simple CMake setup - promise ;) See the instructions for more details: https://invent.kde.org/sdk/clazy/#build-instructions

Any feedback and contributions are appreciated - let’s make Clazy better together 😎. Please report bugs or suggestions on https://bugs.kde.org/enter_bug.cgi?product=clazy or https://invent.kde.org/sdk/clazy/-/issues.

Welcome to a new issue of This Week in Plasma!

Every week we cover the highlights of what’s happening in the world of KDE Plasma and its associated apps like Discover, System Monitor, and more.

This week UI and feature work for Plasma 6.5 continued to progress, along with a bunch of nice technical changes and bug fixes. Have a look:

Notable New Features

Plasma 6.5.0

For supported printers, plasma now tells you when the printer is low on ink! (Mike Noe, link)

Notable UI Improvements

Plasma 6.4.4

Notifications marked as “low priority” or that you’ve manually configured to now show up in the history now selectively ignore that, and do show up in the history when they arrived during Do Not Disturb mode. The reason for this is that otherwise these notifications would simply vanish, and you’d never get a chance to see them at all. (Niccolò Venerandi, link)

The hitboxes for items on the desktop now match the visual styling; no more clicking in an empty-looking place and getting a file or folder selected despite no hover effect! (Niccolò Venerandi, link)

Plasma 6.5.0

Key repeat has been disabled for a number of global shortcuts that could trigger rapid full-screen flashing if you held down the shortcut, because this risks causing seizures in photosensitive people. Affected actions include toggling Overview, full screen mode, maximize/de-maximize, and inverting the screen colors. (Ritchie Frodomar, link 1, link 2, and link 3)

The “Someone started sharing this screen” notification now appears only after the connection has been fully established and screen sharing has actually begun, rather than at the moment when the connection was initiated. (David Edmundson, link)

The “Confirm deleting network connection” dialog now uses standard KDE styling. (Renner 03, link)

The spacing between menu items in the Global Menu widget is now more consistent with menus in individual windows. (Rebecca Bee, link)

Notable Bug Fixes

Soon

Plasma Browser Integration’s browser plugin no longer breaks random features or various known video conferencing websites when its enhanced media controls setting is active. (Kai Uwe Broulik, link)

Plasma 6.4.4

Fixed a bug that caused KWin to crash on the next login when you enable the magnifier effect but don’t use it to zoom in at all before logging out. (Xaver Hugl, link)

Fixed a bug that caused KWin to crash on login when run in a QEMU virtual machine using the Bochs video driver. (Xaver Hugl, link)

Fixed the Global Menu widget’s single-button mode for X11 users too. (Kishore Gopalakrishnan, link)

The search field in the Wayland version of the Global Menu widget once again works. (Niccolò Venerandi, link)

Fixed a bug in the KDE’s implementation of the Global Shortcuts XDG portal that confused apps into thinking they had no shortcuts after you accepted the dialog to make some changes. (David Redondo, link)

Fixed a bug causing notifications in the history view to not appear in sequential order. In case you remember this previously being advertised as fixed, it was, because we worked around a Qt bug that was causing the issue. Well, that Qt bug got fixed, causing our workaround to re-introduce the bug! Software development is hard. (Kai Uwe Broulik, link)

Plasma Browser Integration’s built-in Share feature once again works. (Kai Uwe Broulik, link)

Plasma 6.5.0

Cross-app window activation/raising now works more reliably in a couple cases, and also now works for files opened from KRunner-powered searches except for the Recent Documents runner, which is also being worked on. (Kai Uwe Broulik and Xaver Hugl, link 1, link 2, and link 3)

Fixed a bug that prevented the virtual keyboard from being able to enter text into the Application Dashboard widget’s search field. (Arnav Rawat, link)

Fixed a layout bug that caused the contents of the “Set up a printer connection” page to visually overflow when opened from the “New printer detected” notification. (Mike Noe, link)

When accessed from Plasma (not System Settings), wallpaper grid items now follow the Plasma color scheme, rather than the app color scheme. This is relevant when using a mixed light/dark Global Theme like Breeze Twilight. (David Redondo, link)

Frameworks 6.17

KRunner-powered search results once again take into account frequency of use. (Nate Graham, link)

Other bug information of note:

• 4 very high priority Plasma bugs (same as last week). Current list of bugs
• 28 15-minute Plasma bugs (down from 32 last week). Current list of bugs

Notable in Performance & Technical

Plasma 6.4.4

Fixed a source of inotify leaks caused by reconfiguring the Plasma Desktop or the Folder View widget to show a different folder. (Harald Sitter, link)

Plasma 6.5.0

Implemented support the the pointer_warp_v1 (“Pointer Warp”) Wayland protocol that allows apps to ask the compositor to move the pointer. (Xaver Hugl, link)

XDG portal-using apps can now explicitly request a screencast or remote desktop session of a new virtual output. (David Redondo, link 1 and link 2)

Added some more autotests for basic Plasma widget loading functionality. (Nicolas Fella, link)

The clipboard configuration window’s size and position are now stored in the state config file, not the settings config file. (Nicolas Fella, link)

How You Can Help

KDE has become important in the world, and your time and contributions have helped us get there. As we grow, we need your support to keep KDE sustainable.

You can help KDE by becoming an active community member and getting involved somehow. Each contributor makes a huge difference in KDE — you are not a number or a cog in a machine! You don’t have to be a programmer, either; many other opportunities exist!

You can also help us by making a donation! A monetary contribution of any size will help us cover operational costs, salaries, travel expenses for contributors, and in general just keep KDE bringing Free Software to the world.

To get a new Plasma feature or a bugfix mentioned here, feel free to push a commit to the relevant merge request on invent.kde.org.

Kdenlive 25.08 Release Candidate is ready for testing. While this release focuses mostly on bug fixing, the dev team still managed to sneak in some cool features during the summer heat. Some highlights include:

• Optimized interface for lower resolution screens
• Project files are now properly recognized and can easily be opened by clicking them on MacOS
• Fix location of title templates on Windows
• Fix downloadable keyboard schemes
• Fix python 3.13 compatibility for Whisper
• Added power management support to prevent sleep while playing / rendering
• Support for start timecode
• Added option to display the markers of all clips in the project in the guides list
• Show thumbnails in the guides list
• Redesigned mixer

Download the binaries from below and give it a spin. Please share your feedback in the comments if you encounter any bugs or have a suggestion to help us polish the final release.

Pre-release binaries can be downloaded here.

Intro

This week builds on the work from last week, where I started adding selection action buttons to the floating toolbar in Krita. The focus this time was on integrating more actions and improving the user interface by adding icons to those buttons.

Adding Buttons and Icons

After learning how Selection Tools are triggered through existing UI buttons, the next step was figuring out where those actions originate in the code and how to reuse them in new buttons. I also explored how to visually represent each button using Krita's icon system.

Here’s a simple example of how I added an icon to a button:

d->buttonCopyToNewLayer = new QPushButton();
d->buttonCopyToNewLayer->setIcon(KisIconUtils::loadIcon("duplicateitem"));
d->buttonCopyToNewLayer->setIconSize(QSize(25, 25));

This pattern forms the basis for a reusable template I can follow as I implement additional action buttons across the toolbar.

Finding Icons

Icons play a huge role in usability. Much like how we can recognize cartoon characters by their silhouettes, users often identify tools in a UI by their icons. Good icons make interfaces faster to use and easier to understand.

To find appropriate icons for my buttons, I’ve been referencing these sources:

Krita’s official icon library:
scripting.krita.org/icon-library

Krita source file:
$KRITASOURCE/krita/krita.action

If I couldn’t find an icon there, I searched the codebase for related keywords or looked at how similar tools were implemented with icons. When I exhaust these options, I can also reach out to @Animtim who helps create Krita's custom icons.

Conclusion

Buttons are most powerful when they’re not only functional but also accessible and visually intuitive. This week extends on the work from last week

Next on my list, while I continue adding selection buttons and icons, is to make the floating selection bar movable on the canvas!

Contact

To anyone reading this, please feel free to reach out to me. I’m always open to suggestions and thoughts on how to improve as a developer and as a person. Email: ross.erosales@gmail.com Matrix: @rossr:matrix.org

Hello everyone! Midterm evaluations are here, and I wanted to share an update on my GSoC project. Here’s what I’ve accomplished so far:

Progress So Far

Migration of Existing Fuzz Targets

The first step was migrating the existing build scripts and fuzz targets from the OSS-Fuzz repository into the respective KDE repositories. Maintaining them within the OSS-Fuzz repo added a bit of friction when making changes. Having them in KDE repos makes it easier to maintain and update them.

KArchive Fuzzer

Then I worked on KArchive fuzzer doing mainly two changes: First was to split the fuzzer into separate targets for each archive format (like zip, tar, 7z, etc.) to improve coverage. Second was to add libFuzzer dictionary files to guide the fuzzing process better. Here is an image showing the coverage after these changes:

This coverage was tested using a local corpus and it is pretty solid for just fuzzing the “reading” part. The coverage will increase on OSS-Fuzz by time as the corpus keeps growing. Splitting the fuzzer into multiple targets allows the fuzzer to focus on specific archive formats, which keeps the corpus size smaller and more efficient.

KMime Fuzzer

After that, I focused on KMime. I created a fuzz target for it, which focused on the just the MIME parsing functionality. The parsing part of KMime is critical as it handles untrusted input, such as, from emails (in KMail).

For KMime, I also added a libFuzzer-style dictionary file to help guide the fuzzing process. This helps the fuzzer generate more meaningful inputs, which can improve coverage and help the fuzzer reach deeper code paths.

KDE Thumbnailers Fuzzer

After KMime, I moved on to KDE Thumbnailers. I created a fuzzer for the thumbnailers that are used in KDE applications to generate previews of files. This is important as it handles untrusted input from various file formats, such as images, documents, etc. KDE has a lot of thumbnailers, I started with the thumbnailers in KIO-Extras repository, which includes thumbnailers for various file formats like images, videos, documents, etc.

KDE Thumbnailers were tricky to fuzz because they aren’t standalone. They depend on KIO and KIOGui, which are pretty heavy and pull in a bunch of dependencies not required for thumbnailing. Building the full KIO stack inside OSS-Fuzz would have made the build process slow and complicated.

To avoid that, I wrote a custom build script that compiles just the thumbnailer source files and their direct dependencies. That keeps the fuzzers lightweight and focused only on the thumbnailing functionality.

For these thumbnailers, I also created a dictionary file for each thumbnailer separately for the same reason as KMime.

KFileMetaData Fuzzer

At last, I worked on KFileMetaData. This library is used to extract metadata from files, such as images, videos, documents, etc. Same as KDE Thumbnailers, it handles untrusted input from various file formats, so fuzzing it is important to ensure it can handle malformed or unexpected data gracefully.

Initially, I made a single fuzzer that used Qt plugin system to load metadata extractors and ran the extractors based on content mimetype. However, this required using dynamic libraries which is not great for OSS-Fuzz integration. So I split the fuzzer into multiple targets, one for each extractor, and compiled them statically. This way, each fuzzer is focused on a specific extractor and doesn’t depend on dynamic linking.

The thumbnailers and kfilemetadata currently have the highest coverage among all the fuzzers I’ve created so far, which is great! The coverage will improve and reach closer to 100% for them as the corpus grows on OSS-Fuzz.

What’s Next

There are still many more libraries that could benefit from OSS-Fuzz integration. Here are some that I plan to work on next:

More Thumbnailers

KDE maintains a large number of thumbnailer plugins, and I intend to integrate as many of them as possible. The next ones on my list (provided by Albert Astals Cid) include:

• Calligra Thumbnailer
• Itinerary Thumbnailer
• Qui Thumbnailer
• KDE Graphics Thumbnailers
• MLT Thumbnailer
• KDE SDK Thumbnailers
• WebArchive Thumbnailer
• Pala Thumbnailer
• Font Thumbnailer

Okular Generators & QMobipocket

QMobipocket is a library used by Okular for reading .mobi files. It parses Mobipocket documents and could benefit from fuzzing to identify edge cases and potential vulnerabilities.

Okular also includes several generators responsible for rendering various document formats. While most rely on third-party libraries, a few include custom code that has not yet been fuzzed. These components may be susceptible to bugs triggered by malformed files.

Fuzzing these generators is a bit tricky, since building the full Okular application and all its dependencies would slow down the build process and make its maintenance harder. To address this, I plan to build only the relevant generator source files and their minimal dependencies similar to the approach I used for KDE thumbnailers.

KContacts (VCard Parser)

KContacts is a KDE framework for handling contact data. It includes a VCard parser that reads .vcf files. Although the format is relatively simple, it supports multiple character encodings and codecs, making it an interesting candidate for fuzz testing.

Links

• Intro Blog post: azharmomin.me/posts/gsoc-2025-expanding-oss-fuzz-integration-across-kde-libraries

That’s it for now. If you’re working on/know a KDE library that touches untrusted input and could benefit from fuzzing, please let me know! You can reach me on Matrix or Email.

One of the biggest things you can do for KDE (that does not involve coding) is helping us organize Akademy.

In 2026, we are organizing a special edition of Akademy to celebrate KDE's 30th birthday. We want to make this occasion memorable by celebrating this important milestone with Akademy. The birthday edition of Akademy will not only bring together contributors, users, and partners but will also reflect on three decades of community, collaboration, innovation, and Free Software.

Now is your chance to become KDE champions and help make Akademy 2026 happen! We are looking to host Akademy 2026 during June, July, August, September, or October. Download the Call for Hosts guide and submit a proposal to host Akademy in your city to akademy-proposals@kde.org by October 1, 2025.

Do not hesitate to send us your questions and concerns! We are here to help you organize a successful event, and you can reach out at any time for advice, guidance, or any assistance you may need. We will support you and help you make Akademy 2026 an event to remember.

This year there was another “Display Next Hackfest”, this time thanks to AMD organizing and hosting the event at their office in Markham, Toronto. Just like the last hackfests, there were other compositor developers and driver developers present, but in addition we had the color experts Charles Poynton and Keith Lee to pester with questions, which was very useful. In general, the event was very productive.

We discussed a lot of things, so this is just a summary of what I personally consider most important, not exhaustive notes on every topic. You can read the full notes on Harry’s blog.

Commit Failure Feedback

Currently, when the compositor tries to commit changes to KMS and that fails, it almost always just gets -EINVAL as the response, in other words “something doesn’t work”. That’s not just annoying to debug, but can lead to the compositor spending a lot of time with useless atomic tests in some situations, like for example when KWin tries to turn displays on - I’ve seen cases where we spend multiple seconds testing every possible configuration of outputs (while the screen is frozen!), just for the actual problem to be unfixable without turning one of the displays or some feature off.

So we discussed how to improve on that, and the result was basically that we just want something - really anything is better than the current situation. We found that there’s a reserved field in the atomic ioctl, so we can even do this without introducing a completely new ioctl and just make that reserved field an optional pointer to another struct in which the kernel will write the feedback on what failed exactly. The most basic things we agreed to start with are to return

• some enum for common issues, like limited scanout/memory bandwidth, limited connector bandwidth, invalid API usage, things like that
• some string with possibly driver-specific information that the compositor can log, most important for debugging problems on user systems
• an optional array of KMS object IDs for what objects are related to the failure, for example for which connectors are hitting bandwidth limits

New Backlight API

The current backlight API on Linux is that the kernel exposes one or multiple backlight related files in sysfs, and userspace writes to one of them with root permissions. This requires heuristics for which one of the files is the correct one to use, this API can only control a single backlight, it can’t be synchronized to the image a compositor presents, the firmware may or may not do animations, it may be linear or not, the minimum brightness is completely undefined (sometimes it’s zero!), in summary it’s a total mess.

Three years ago there was a proposal to add a backlight API to KMS instead, which however stalled as the author had to work on other tasks. We discussed on what exactly we want from that API:

• a backlight property per connector
• optional additional information about the mapping of backlight values to actual luminance (min/max values, linear/nonlinear curve)
• (where possible) no animations in the firmware
• (where possible) atomically update the backlight with the rest of the atomic commit, so we can properly synchronize content and light level for HDR on SDR displays

Adaptive Backlight Management

ABM is a feature on some AMD hardware, which reduces backlight intensity to save power and at the same time increases contrast of colors on the screen to compensate for that reduced backlight level. This is a bit of a controversial feature - on one hand it improves battery life, but on the other it messes with the colors on your screen, which to some people just doesn’t look good but is really bad if you’re trying to do color critical work.

Currently this feature is controlled through sysfs, which means power management daemons can mess up your colors without you being aware. Additionally it would be nice to automatically turn off the feature when you’re profiling your screen with a colorimeter, and as the feature reduces the backlight, also in very bright environments to get that extra brightness… To improve on that situation, we’ll get a KMS property to control the feature from the compositor side. I intend to make it off by default in Plasma, but users that want additional battery life will be able to easily opt into it in the display settings.

Autotests

We had three discussions about automatic tests - one about measuring power usage, one about testing KMS drivers, and one about testing compositors.

For power usage tests, we didn’t really agree on the best way to get a standardized testing framework, but we found some possible approaches that can work now - tests can be automated to some degree by using compositor-specific APIs, the remote desktop portal or OpenQA.

For testing KMS drivers, we talked a bit about how the IGT test suite is useful for testing specific cases, but it doesn’t really cover all the same bits that real world compositors use. The tests mostly use features in a somewhat self-contained manner, are mostly written by kernel developers, and thus test how they expect their APIs to be used, which is sometimes different from how compositors actually use it. A possible solution for that is for compositor developers to write automatic tests using their compositor, which run directly on KMS and execute some pre-programmed sequence of events, possibly requiring KMS features like color pipelines or overlay planes to be used successfully for the test to pass.

We still have to figure out the details, but if we can get compositors in DRM CI, that could help improve stability of both compositors and drivers.

Last but not least, for testing compositor’s KMS usage, we can’t really rely on our manual testing with actual hardware, and DRM CI tests will still be somewhat limited. Some compositors already use VKMS, a virtual KMS driver, for their automatic tests, and there are some pending kernel changes for configuring it to do a lot more than the rather simple and fixed setup we had so far. With the new API, we’ll be able to configure it to have nearly arbitrary amounts of planes, add and remove connectors and even entire GPUs! I still have to wire up a KWin autotest for this, but it will be very useful both in development and to prevent regressions in releases.

Color and HDR

We of course also spent a lot of time talking about color management and HDR, and started that off with the current state of implementations. Things are looking really good!

In terms of Wayland protocols, all the important bits are in, namely the color management and color representation protocols. There may still be some smaller changes to the protocols, maybe some additions here and there, but the most important parts are done and used in practice. If you’ve read my previous blog posts, you might know that KWin’s color management story is in a really good state, but other compositors are getting there as well. While Mutter is still lacking non-HDR color management bits, it now has basic HDR support, the Cosmic compositor has some preparations for it going on under the hood, and wlroots has basic HDR support as well.

On the application side, lots of applications are working on supporting it, like Qt, GTK, Godot and Firefox, or support it already, like Mesa, mpv and gamescope. Notably, Blender even has currently Wayland-exclusive HDR support!

We had a Q&A and some discussions with Charles Poynton and Keith Lee. For details you can look at the notes, but the most important thing I took from it was that we should adapt visuals to the user’s viewing environment based on their absolute luminance too, not just the relative light levels. How to actually do that adjustment in practice isn’t entirely figured out yet though, so that will be an interesting problem to solve.

We also talked a bit about the drm color pipeline API. I won’t go into details about this one either, but I’ll talk more about it my next blog post. TL;DR though is that this API allows us to use many more color operations that GPUs are capable of, to avoid compositing with shaders in more situations. I have a KWin implementation that proves the API works and by now the API and driver implementations basically just have to be merged into the kernel.

My “Favorite”: Pageflip Timeouts

Judging by how often I come across this issue in bug triage, if you’re reading this, chances aren’t too terrible that you’ve heard of this one already, possibly even seen it yourself in the form of

kwin_wayland_drm: Pageflip timed out! This is a bug in the amdgpu kernel driver
kwin_wayland_drm: Please report this at https://gitlab.freedesktop.org/drm/amd/-/issues
kwin_wayland_drm: With the output of 'sudo dmesg' and 'journalctl --user-unit plasma-kwin_wayland --boot 0'

in your own system logs at some point. To be clear, this is just an example and it does not only affect amdgpu. I’ve seen the same with NVidia and Intel too, but as amdgpu’s GPU resets have been a lot less reliable in the past, it’s been a bigger issue for them.

Basically, pageflip timeouts are when the compositor does an atomic commit through KMS, and then waits for that to complete… forever. When this happens, the kernel literally doesn’t allow the compositor to present to the screen anymore, so the screen is completely frozen forever, which is very bad, to state the obvious.

Fixing all the individual causes of the problem hasn’t really worked out so well, and this is a bad enough situation that there should be a way out when it does happen. We discussed how to do this, and I’m happy to report that we figured out a way forward:

• we need a new callback in KMS that tells compositors when a pageflip failed and will never arrive
• drivers need to support resetting the display-driver bits of the GPU to recover it
• if the driver entirely fails to recover in the absolute worst case, it should send a device wedged event, which tells the compositor it should try to reload the entire driver / device

Scheduling Atomic Commits

When presenting images to a display, compositors try to get the absolute lowest possible latency achievable, without dropping frames of course. This is tricky enough with full information about everything, but it’s even worse if information is missing.

Currently, KWin just tries to commit 1.5ms before vblank start of a refresh cycle. This number was figured out experimentally - on a lot of hardware, we could easily reduce latency by 500µs-1ms without any issues, and on some other hardware we’d even need more latency to never drop frames! The latter problem I kind of already fixed by measuring how long each commit takes, but that just measures the CPU time, and not when the hardware is actually done programming the next frame. We also don’t know the deadline, on lots of hardware it is the start of vblank, but with some drivers it may be later or earlier.

We discussed how this could be solved, and concluded that we want

• a callback that gives us a timestamp for when the hardware finished programming the last commit
• information on when the deadline is, relative to the start of vblank

Variable Refresh Rate for the desktop

We want to use VRR to save power, not just to reduce stutter in games. However, for that we really want some additional APIs as well:

• the compositor should be able to set a min and max refresh rate, for example for low framerate compensation (LFC) and for flicker reduction
• the compositor should be able to do LFC instead of the driver having heuristics for that - so we need to be able to turn driver-side LFC off
• on the Wayland side, it would be nice for video players to be able to report their preferred refresh rate, so we can set the display to a multiple of the video. Should be a really simple Wayland protocol, in case anyone wants to do it before I get around to it ;)
• also on the Wayland side, a maximum desired refresh rate for games could be useful

Slow atomic commits

Amdgpu has some issues with atomic test commits being very slow, more specifically when it comes to significantly changing overlay plane state - on my desktop PC, enabling and resizing overlay planes regularly makes the test take tens of milliseconds. On my laptop it’s a lot faster for some reason, where it’s usually not noticeable, but even there a lot of tests take 1ms or more. We may need to do multiple atomic tests per frame, especially when you move the cursor… so that’s still quite bad!

We can work around the problem in the compositor to some degree, by avoiding frequent changes to the overlay plane state - we’ll certainly try to make it good enough to leave the feature on by default. Either way though, someone ‘just’ has to optimize this on the driver side, otherwise you might still see some stutter when enabling or disabling overlay planes.

Actual Hacking

It wouldn’t be a proper hackfest without any hacking of course! Before the event, I was working on overlay plane support for a while, and added color pipeline support on top of my WIP code for that. In terms of KMS offloading, the only big feature that was still missing is underlay support… so I added that at the hackfest. Turns out, if you already have complete overlay plane support, adding underlays to the mix isn’t actually all that difficult.

The code still need some cleaning up and not all of it is merged yet, but on my laptop it’s now basically a challenge to get KWin to not put videos and games on hardware planes, and the result is amazing efficiency for video playback and improved latency and performance for gaming in windowed mode. This is a larger topic though and deserves its own blog post soon™, so I won’t explain how it works here.

Tourist-y things

AMD invited us to go up the CN tower. It was a little bit foggy, but we still had a good view of the city:

I also visited Niagara Falls. It was a sight to behold!

Conclusion

Thanks again to AMD for hosting the event, it was really fun. There might not be another display hackfest next year, as most of the big topics are finally nearing conclusions, but I hope to see many of the other hackfest participants again at other events :)

In this blog you will learn how to set up clang-format with Qt Creator for consistent, automatic code formatting, including custom style files and exclusion rules for subdirectories.

Continue reading Using clang-format in Qt Creator at basysKom GmbH.