GSoC 2026 • digiKam • Post 1: Design and Progress

I’ve been hanging around KDE apps since I was a teenager :), so getting to spend another summer inside one feels a bit like coming home. This time it’s digiKam!

Here’s what I want digiKam to do: Let me type “photos of mountains from last summer that I rated highly” into a search box, and have it just… find them. No complex filters, no guessing where to click, just plain English, the way you’d ask a friend who’d been on the trip with you.

That, in one sentence, is my GSoC project: interfacing digiKam’s search engine with an AI-based LLM so you can search your photo collection in natural language. For many users, digiKam’s Advanced Search is a hidden gem, powerful but a little intimidating. By adding natural language support, we’re making it accessible to everyone, from beginners to experts who want to save time. And as someone who’s used KDE apps for years, I loved the idea of bridging the gap between digiKam’s powerful features and the simplicity of just asking for what you want.

I’d recently been deep-diving into transformers, and this project stood out to me as a near-perfect blend: real software development and having to actually understand LLMs, which architectures fit where, when you want an encoder versus a decoder, and how a model behaves once it’s wired into an actual application.

This first post is about the overall design and the progress so far. The more interesting bits about the actual language model: which one, how fast, how accurate, are coming in a second post, so consider this the scene-setting.

(Mild Technical Content Ahead, but I promise to keep the scary parts optional. ;) )

The one idea the whole project rests on

DigiKam already has a powerful Advanced Search feature: a dialog packed with dropdowns for tags, dates, ratings, albums, color labels, and more. It can handle complex queries, but it requires users to know how to navigate it.

So the LLM in my project does NOT search your photos. Let me say that again, because it’s the most important design decision: the model never touches your database, never decides what matches, never invents results. All it does is translate your sentence into the exact same structured query you could have built by clicking the dialog yourself. The model produces an “intent”; digiKam’s existing, trusted search engine does the actual searching.

I like this framing because it keeps the AI firmly in its lane. The LLM is a translator sitting in front of a door that already exists: it’s not a new door, and it definitely isn’t allowed to wander off and make things up. Anything it produces is something a human could have produced by clicking. That’s the safety guarantee, and everything in the pipeline is built to enforce it.

The Pipeline in Action

Here’s the journey your query takes:

Your sentence
     |
     v
[ Prompt Builder ]  : wraps it with format instructions
     |
     v
[ Language Backend ]  : runs the model, returns raw output
     |
     v
[ Intent Parser ]  : validates strictly; rejects anything malformed
     |
     v
[ Capability Dictionary ]  : maps human words to digiKam's real fields
     |
     v
[ Intent Resolver ]  : builds concrete search criteria
     |
     v
Advanced Search widgets populated —> digiKam runs the search

Walking through it:

1. You type a sentence.
2. A prompt builder wraps it in instructions that tell the model exactly what format to answer in.
3. A language backend runs the model and gets back its answer.
4. An intent parser reads that answer and crucially validates it strictly. The model’s output is never trusted directly. If it isn’t well-formed and doesn’t match the known fields and operators, it’s rejected outright. No partial guessing.
5. A capability dictionary maps fuzzy human words to digiKam’s real fields: “best” might mean a high rating or an “Accepted” pick label, “colour label” maps to the actual colour-label field, and so on.
6. An intent resolver turns the validated, mapped intent into concrete search criteria.
7. Those criteria populate the Advanced Search widgets, and digiKam runs the search exactly as if you’d filled them in by hand.

The nice consequence of splitting it up this way is that the model can be as small and dumb as we like, every layer after it is busy double-checking its homework. If the model says something nonsensical, the parser catches it. If it names a field that doesn’t exist, the dictionary won’t map it. By the time anything reaches your database, it’s been laundered through several layers of “is this actually a thing digiKam can do?”

Why Local Models?

A quick but important detour. The model runs locally on your own machine, not in some company’s cloud. Running the model locally isn’t just about performance - it’s about privacy.

And privacy matters more here than it might first appear. Think about what’s actually in a photo library: where you live, who your family and friends are, where you travelled and when, the inside of your home, your children, the events that matter to you. A photo collection is one of the most personal things a person keeps on a computer. And the searches you run over it are revealing in their own right, the words you’d type to find a photo say something about what you’re looking for and why.

If any of that were sent off to a remote server to be processed, you’d be trusting a third party with exactly the information most people would least want to hand over. Running everything on-device sidesteps that entirely: your photos never leave your machine, your queries never leave your machine, and there’s no account, no API key, and no internet connection required. The feature works the same on a plane as it does at home.

The catch is that a local model is a big file you have to get onto people’s computers somehow which brings me to the part I spent most of this period actually building.

Plugging into digiKam’s Infrastructure

C++ has been my favourite language since my teens, and one of the quiet pleasures of this project has been getting to brush up on it properly. Qt, though, is a different story and a familiar one if you’ve read my Krita posts. Every term I spend with Qt I learn a little more, and every term I’m reminded that it’s one of the harder frameworks to get comfortable in, precisely because it leans so heavily on design patterns. You don’t really “learn Qt” so much as slowly stop being surprised by it.

When I first thought about “the model needs to be downloaded onto the user’s computer,” my instinct was to just write something that downloads a file. Simple enough. But that instinct was wrong. digiKam already knows how to download large model files. It’s been doing it for years, for face recognition, object detection, auto-rotation, aesthetics scoring. There’s a whole system for it: a central DNNModelManager that reads a config file describing each model, and a FilesDownloader that fetches the files from KDE’s servers and verifies them. My mentor’s guidance was clear and correct: don’t build a parallel download mechanism, plug into this one.

The wrinkle is that this entire system was built for OpenCV vision models - models that look at images. My model is a language model run by a completely different library (llama.cpp). It’s a different kind of beast that doesn’t fit the OpenCV machinery at all.

The solution turned out to be pleasingly modular. By creating a lightweight DNNModelNaturalLanguage class, I was able to plug into digiKam’s existing model download system without modifying its core logic. This means the GGUF file is downloaded, verified, and managed just like digiKam’s other AI models (e.g., for face recognition). There’s an existing model type in digiKam (DNNModelConfig) that registers and verifies a file but does no OpenCV loading and that was almost exactly the shape I needed, so my wrapper mirrors it. The actual loading and running of the model happens separately, in a SearchLlamaBackend that talks to llama.cpp.

So the division of labour is clean: digiKam’s existing system handles getting the file onto your computer (download, checksum, the works), and my llama.cpp backend handles running it. No duplication, and my model gets to ride the same well-tested rails as every other model in digiKam.

Why Qwen2.5-1.5B-Instruct

A word on the model itself (much more in post two). I went with Qwen2.5-1.5B-Instruct, in a quantized GGUF form, for a few reasons:

• Size vs. capability. At ~1.12 GB (Q4_K_M quantization) it’s small enough to download and run on a normal laptop, but the 1.5B-Instruct variant is genuinely good at following instructions and producing structured JSON, which is exactly what I need it to do.
• It’s good at the specific job. This project lives or dies on the model reliably emitting clean, parseable, schema-shaped output. Qwen2.5 is notably solid at structured outputs.
• The licence. It’s Apache 2.0, so it’s freely redistributable, which means KDE can actually host the file on its own infrastructure. Why a decoder-only model (and not BERT)

Before picking a specific model, I had to pick a kind of model and this is one of the places my transformers reading actually paid off, so indulge me for a paragraph.

The obvious-seeming choice for “understand a sentence and classify it” is an encoder model like BERT. Encoders are efficient, deterministic, and great at fixed-label tasks. But they assume a finite, predefined output space and that’s exactly what search queries don’t have. A query can express any number of constraints (“landscape photos with red labels near Paris last summer” is four constraints at once), and I’ll keep adding new searchable dimensions over time. To force that into an encoder, I’d need a pile of auxiliary pieces: intent classifiers, entity extractors, rule-based combiners and that scaffolding gets more brittle every time digiKam gains a new search field.

A decoder-only model sidesteps all of that. It generates a sequence, so it can emit a variable number of structured constraints directly as JSON, following a schema I define in the prompt. New search field? Update the schema and no retraining. And it handles ambiguity gracefully: instead of being forced to pick one interpretation of “best photos,” it can emit a clarification request inside the same constrained output. (Encoder-decoder models like T5 could generate structured output too, but they carry extra architectural and latency overhead that’s wasteful for a local, on-demand desktop feature.)

So the short version: a small decoder-only model gives me compositional, schema-shaped generation with built-in ambiguity handling, at a size that runs on a laptop. That’s the whole wishlist.

All assuming 4-bit (Q4) quantization in GGUF form, which is the standard for CPU inference with llama.cpp:

The pattern is a straightforward size-vs-capability trade-off. The bigger models (Phi-3 Mini, Qwen2.5-3B) reason better but want more RAM and run slower on a CPU-only laptop and since this feature has to stay usable on ordinary hardware without a dedicated GPU, “runs comfortably in ~1 GB of RAM” is a hard constraint, not a preference. That rules the heavier models out for the default.

Among the lightweight options, Qwen2.5-1.5B-Instruct hits the sweet spot: small enough for a CPU laptop, but notably reliable at the one thing this project actually needs: emitting clean, schema-shaped structured output. TinyLlama 1.1B stays in the picture as a fallback for lower-end machines where even 1.5B is too much. Both are Apache 2.0, which (as above) is what makes KDE hosting possible, a point that quietly eliminated some otherwise-tempting models with restrictive licences.

Where things stand

The pipeline already works end-to-end using a mock backend (standing in for the real model). So, prompt > parse > resolve > populate-the-search-and-run is all functioning and unit-tested. And the download integration I described above is in place: the model is registered with digiKam’s central manager, and I’ve verified it gets picked up correctly and its file path resolves to the shared model directory.

What’s Next?

• Host the GGUF model on KDE’s infrastructure (in progress).
• Wire up llama.cpp for local inference.
• Benchmark Qwen2.5 vs. TinyLlama on digiKam-specific queries (e.g., “5-star photos”, “pick label accepted”).
• Dive into model performance, fine-tuning, and caching!

Found an excuse to start drawing again :)

In my last post on Android platform integration I had suggested increasing the focus on Linux on mobile phones, due to Google’s ongoing attempts to close down Android for us. I have to follow that myself then of course, starting with looking at the situation around location/positioning.

What we have

The positioning stack looks roughly as follows as far as KDE applications are concerned:

• Geoclue collects positioning data from various sources (GNSS receiver, cell modem, online service, etc) and provides a D-Bus API for it.
• XDG Desktop Portal has a Location API for exposing this to sandboxed applications, including permission handling. XDG Desktop Portal itself uses Geoclue as its source.
• Qt Positioning provides the application-facing API for retrieving position data, and QLocationPermission provides the API for requesting permissions when running sandboxed.

There’s two main gaps here though:

• Qt Positioning only has a Geoclue backend, not one for the XDG Desktop Portal Location API. This means we wont have access to positioning information in a sandbox.
• Qt’s entire permission API has only a dummy implementation on Linux, meaning it will always claim all permissions have been granted, which isn’t true in a sandbox.

What I couldn’t look into is whether Geoclue is able to actually retrieve GNSS data on “real” hardware, lacking access to devices to test this on.

Developer Tooling

Testing GNSS code with real hardware is rather inconvenient anyway, you have to move around for this, and quite a bit even when you also want to test various edge cases. Much better would be a way to inject arbitrary GNSS data low enough in the stack.

Many years ago I had built something like this for GammaRay, but that works on the level of Qt Positioning, which is above the parts we want to test here. Fortunately Geoclue offers us a way to do this as well. It’s looking for _nmea-0183._tcp mDNS services that provide a NMEA 0183 feed, and will use that as a source for GNSS data.

NMEA 0183 is a decades-old serial port protocol for GNSS equipment, easy enough to implement. As there are more usecases for this below, there’s now a small library setting up such a services, announcing it via mDNS and sending NMEA 0183 messages. NMEA 0183 defines two dozen or so different message types, but since Geoclue only looks at GGA and RMC ones those are all we need.

Then all we need is a little GUI on top of this to select inputs on a map and have that fed into Geoclue. As a bonus we also have GPX track replay, so you can get a continuous feed of position updates automatically. The code is here.

XDG Portal plugin for Qt Positioning

Being able to “move” around the world from the convenience of my desk/couch made it then easy to implement the main missing piece here, connecting Qt Positioning to the XDG Desktop Portal Location API. The code is here, it’s just a couple of D-Bus calls and a bit of boilerplate needed for positioning plugins.

It’s registered with a higher priority than the Geoclue plugin and will be skipped if the portal API is not available.

QPermission API

That still leaves the permission handling. Qt’s API for that lives in Qt Core, so we cannot just implement support for XDG protal permissions there, as that needs dependencies from higher up in the stack, such as D-Bus and window ids.

There’s an easy way out though, by generalizing an already existing permission plugin system that so far is only provided on Apple platforms. A patch to Qt enabling this on Unix systems as well is in review currently. With that applied implementing support for requesting location permissions is then very similar to what the positioning plugin already does, you’ll find the code here.

A very convenient side-effect of having permission plugins is that we can now also build a “simulator” that allows testing permission flows in applications while running in an unrestricted development environment and without having to mess with system permission settings each time.

So I did that here, usage is pretty simple:

$ qpermission-simulator [--ask|--grant|--deny] <application-to-test>

Note that this also needs the above mentioned Qt patch to actually do anything, and it currently requires the tested application to be a QApplication in order to show its UI. It does work for all permission types supported by Qt though, not just the location one.

Other positioning sources

One unique feature that microG offers on Google-free Android is using onboard APIs of planes/trains/buses as a location source. That’s useful as the GNSS antennas of those vehicles tend to give you much better results than the one on your phone inside the metal casing of the vehicle.

Of course we have to have that as well, and it’s easy enough to build that since we have an existing library for dealing with onboard APIs already as part of KPublicTransport.

Putting that together with the NMEA 0183 server we get a small KDED module that watches for changes to the Wi-Fi network you are connected to, and if it’s one of a known onboard API it’ll offer its service to Geoclue. As Geoclue will only connect to it on demand (ie. when an application actually asks for a location) it will only poll the onboard API when necessary, so we also get practically no overhead in the idle state here.

Other sources are possible in a similar way as well, e.g. having KDE Connect provide location data from your phone to your desktop computer.

Feedback

This is mostly the result of about two weeks of prototyping, and I’d very much appreciate review and feedback on this. Does the general approach make sense? Is there something else missing around the the location/position topic? Where should the various components live and be distributed eventually (some of this only really relevant inside a Flatpak sandbox fox example)?

Welcome to a new issue of This Week in Plasma!

This week members of the core Plasma team spent almost all of their time in bug-fixing mode! As usual, people unleashed their real-world setups on the new Plasma release and found some issues we missed during the development process, and that nobody reported during the two beta releases. So we made it a priority to fix those issues!

Plasma 6.7.1 was released earlier this week with the first round of fixes, and 6.7.2 is scheduled for early next week with more.

A few new features and UI improvements started landing, too.

Check it out here:

Notable new features

Plasma 6.8

You can now set up wallpaper slideshows that don’t change automatically. Instead you can manually switch the wallpaper via the item in the desktop context menu or its global keyboard shortcut. (Fushan Wen, KDE Bugzilla #518669)

Added an Esperanto keyboard layout to Plasma’s virtual keyboard. (Daniel O’Neill, plasma-keyboard MR #148)

Notable UI improvements

Plasma 6.7.2

Improved text alignment in System Monitor’s Processes page while using the tree view. (Arjen Hiemstra, KDE Bugzilla #442095)

Plasma 6.8

Reduced the number of visual frames in the Menu Editor app. (Levi Leal, kmenuedit MR #59)

Notable bug fixes

Plasma 6.6.6

Fixed an issue that could make KWin crash when some apps opened dialogs and popups in non-standard ways. (Vlad Zahorodnii, kwin MR #9444)

Fixed a regression introduced by Qt 6.11 that made the word “Undefined” appear next to Places entries in the Kickoff Application Launcher widget. (Christoph Wolk, KDE Bugzilla #521799)

Fixed a visual glitch affecting users of Deskflow that could make a clone of the pointer inappropriately remain visible on the client machine. (David Redondo, KDE Bugzilla #521486)

Plasma 6.7.1

Fixed a somewhat common case where KWin could crash on the lock screen when using an NVIDIA GPU. (Xaver Hugl, KDE Bugzilla #520842)

Fixed a recent regression that made KWin crash when using a DisplayLink monitor. (Xaver Hugl, KDE Bugzilla #520361)

Fixed an issue that could make screens plugged into a laptop with both an NVIDIA and an AMD GPU freeze. (Xaver Hugl and SungHwan Jung, KDE Bugzilla #521727)

Fixed a recent regression that broke certain shader-based KWin effects, including the popular “Burn My Windows” effects. (Xaver Hugl, KDE Bugzilla #521774)

Fixed a recent regression that broke color-related KWin effects like color blindness correction and screen color inversion. (Xaver Hugl, KDE Bugzilla #521737)

Plasma 6.7.2

Fixed the currently most common KWin crash, related to variable refresh rates with multi-monitor setups. (Vlad Zahorodnii, KDE Bugzilla #521909)

Fixed a case where Info Center could crash when trying to display information about certain NVIDIA GPUs. (Harald Sitter, KDE Bugzilla #521295)

Fixed a recent regression that broke the RDP server when run using systemd. Sorry about that! (David Edmundson, KDE Bugzilla #521776)

Fixed a recent regression that could sometimes make Chromium-based apps freeze if another window was forced into “Keep Above Others” mode. (Xaver Hugl, KDE Bugzilla #521687)

Plasma 6.8

Fixed a case where Plasma could crash after you ejected an audio CD from Dolphin or Audex. (Kai Uwe Broulik, KDE Bugzilla #522051)

Flatpak 1.18.1

Fixed an issue that made a background service for Flatpak crash if you used the KDE desktop portal dialog to allow an app to update itself while the app was still running. (Sebastian Wick, flatpak issue #6686)

GTK 4.23.2

Made the process of selecting text to later paste it by middle-clicking more reliable in GTK 4 apps. (Vlad Zahorodnii, gtk MR #10006)

Notable in performance & technical

Plasma 6.7.2

Improved full-screen video playback performance in Chromium-based apps. (Xaver Hugl, KDE Bugzilla #521960)

Plasma 6.8

Turned on triple buffering by default for NVIDIA GPUs, because the bugs blocking this from working properly in the past have since been fixed. (Xaver Hugl, kwin MR #9472)

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.

Would you like to help put together this weekly report? Introduce yourself in the Matrix room and join the team!

Beyond that, you can help KDE by directly getting involved in any other projects. Donating time is actually more impactful than donating money. 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 out by making a donation! This helps cover operational costs, salaries, travel expenses for contributors, and in general just keeps KDE bringing Free Software to the world.

Time to put on my Techpaladin Software had again: we’re hiring! David Edmundson has already posted it, so I’m here to boost the signal: we need you! Especially if you’ve got experience with Qt/KDE development.

We’re looking for someone with that plus an eye for UX & design, and another person with that plus deep tech skills, particularly around I/O and other “system plumbing” topics.

Check it out: https://techpaladinsoftware.com/joinus.html

If you've been around KDE, you've probably heard of Techpaladin Software

We're a consultancy that works almost exclusively on KDE, improving KDE upstream while delivering the features and functionality our clients need.

We're growing and looking for more developers to join the team. We're after experienced developers who are already familiar with KDE, C++, and Qt.

We currently have two positions available:

• Someone with a keen eye for design to work on high-level features and help shape the user experience.
• Someone with a more technical background to work on lower-level system integration and platform work.

In return, you'll get to work with some of the most talented and welcoming developers in this space... and also me!

If that sounds interesting, you can find more information and apply here:
https://techpaladinsoftware.com/joinus.html

KDE Eco organized a two-day sprint to work on KEcoLab — the energy measurement lab I maintain. A few more people came and joined on day two, which made the discussions richer. The sprint was mostly about figuring out the next steps for KEcoLab, fixing some open issues with the measurement pipeline, and trying to get a second system set up in the lab. You can find the full sprint notes here.

Thanks to KDE e.V. for sponsoring the sprint, KDAB for hosting us at their Berlin office, and Volker for the guidance and support throughout.

Headless Remote Access

The first thing we wanted to sort out was making the lab PC fully remotely accessible, which means we could use it without having someone physically in the room to debug our issues with the lab PC. SSH was already working fine, but RDP was not very reliable (it used to break sometimes). Nowadays, We had to go to the lab PC in person once to allow remote connections, which is exactly the kind of thing you do not want to do repeatedly. During the sprint, we applied a fix using flatpak permission-set to persist screen capture permissions across reboots, based on a recently merged patch (plasma/xdg-desktop-portal-kde!326).

However, the issue is not fully closed. A couple of days after the sprint, the problem came back and it was not clear what had changed. We had a follow-up meeting to discuss this, notes here. Joseph and Volker are currently testing different approaches to figure out how to properly persist the session across reboots. We will update this once we have a reliable fix.

Setting Up a Second Machine

Cornelius Schumacher donated a Fujitsu Esprimo 510 to the lab for us to add as a second System Under Test. It did not go well. The machine threw six beeps on boot, which pointed to a CPU or motherboard problem, most likely a BIOS flash failure. We tried reseating the RAM, resetting the CMOS battery, testing each RAM stick one by one. Nothing changed. The machine is not usable, but we are keeping the hardware for spare parts.

Debugging the Okular Pipeline

We ran the full Okular measurement pipeline on Wayland and hit a few problems. On day two, we saw an R error about non-numeric data. When we looked into it, the collectl files had data from pipeline runs we had stopped earlier, stopping a pipeline mid-run was causing the next run to append data to existing files, which broke the statistical analysis. We now have issues open to fix this properly:

• Kill pipeline: #64
• Failsafe for pipeline failure: #18
• Cancel SUS script: #16

A cleanup stage has since been added to the pipeline to handle this — see !152.

The reports also had wrong durations and missing averages. That turned out to be missing stopActions in the ydotool scripts. Once we fixed those, the numbers looked reasonable. Joseph is continuing to work on this and will follow up on the remaining open questions.

There is also a broader question about the data itself. Our power draw results look very different from measurements taken at Umwelt Campus Birkenfeld back in 2022. Their data showed distinct power draw phases across tasks, while ours is mostly flat apart from the spike when Okular opens. It could be Wayland versus X11, Flatpak versus a repo package, or just Fedora versus Ubuntu. Probably a mix of all of them. Something to investigate.

Future Planning

We went through the open issues and talked about what comes next, integrating KEcoLab into a broader KDE Plasma testing workflow, planning for the Akademy BoF, and ideas around extending ydotool/kdotool to make measurement scripts more flexible. We did not get through everything but the direction is clearer now.

Outside the Lab

After the first day, Carl, Aakarsh, Joseph, and I headed to Tempelhofer Feld. It was a warm evening and the field was full of people cycling, skating, and just sitting around. We walked around for a while and talked about everything except KEcoLab, which was exactly what we needed. A big thank you to Carl and Joseph for showing us around, Berlin has a way of making you feel like you have all the time in the world, even when you have a pipeline to fix in the morning.

Not everything worked, but we came away knowing exactly what needs to be fixed and why. That is usually what a good sprint looks like.

Tempelhofer Feld

Let’s go for my web review for the week 2026-26.

Look, just fucking use Mastodon already

Tags: tech, social-media, fediverse, bluesky, decentralized

Aren’t the signs clear enough yet? Don’t get misled by Bluesky.

https://giants-club.net/articles/just-use-mastodon/

W Social, Fictional Metrics and the Beauty of Open Data

Tags: tech, social-media, europe, politics

I wish people will stay clear of this newer social media… It already smells really bad in its practice.

https://blog.elenarossini.com/w-social-fictional-metrics-and-the-beauty-of-open-data/

Apertus LLM Family Expansion via Distillation and Quantization

Tags: tech, ai, machine-learning, gpt, foss

Some news from the Apertus project, they released smaller models. Interesting work.

https://apertvs.ai/articles/2026-06-apertus-mini/

Yale researchers propose ‘copyleft’ rules for generative AI

Tags: tech, foss, licensing, ai, machine-learning, gpt, copilot

This is an interesting proposal, let’s hope it gets picked up and appear in more licenses.

https://news.yale.edu/2026/06/15/yale-researchers-propose-copyleft-rules-generative-ai

Anthropic accuses Chinese rival Alibaba of illicitly extracting AI capabilities

Tags: tech, ai, machine-learning, gpt, copyright, politics

Remind me how your built your models in the first place? Yeah right…

https://www.bbc.com/news/articles/cwyklykn5dwo

The Shared Feeling of Being Harvested by the Future

Tags: tech, ai, machine-learning, gpt, copilot, surveillance, attention-economy, politics, economics

Very sobering opinion piece. For all the talks about a China / USA race, it feels more like two flavors of the same dystopia. The race is just here to justify acting against their own population interest. The result is then the increase in illiberal fixations and nihilistic world views. This can’t end well.

https://www.nytimes.com/2026/05/12/opinion/us-china-ai-future.html?unlocked_article_code=1.qlA.4T9r.BLss9eBMrQot

Echoes of the AI Winter

Tags: tech, ai, history

When you ignore history, you’re bound to repeat the same mistakes. There’s clearly a trend of overpromising and then failing to deliver.

https://netzhansa.com/echoes-of-the-ai-winter/

Show your hands honor for the strange power they bring you

Tags: tech, input, performance, design, history, apple

A long but very interesting piece starting all the way from early typing on machines to more modern input systems. It’s very focused on Apple machines towards the end, but there are good design lessons to draw from the long perspective.

https://aresluna.org/show-your-hands-honor/

It’s Only When You Look Back

Tags: tech, history

Interesting look back at how our industry evolved. Quite a few events over the years.

https://www.markround.com/blog/2026/06/17/25-its-only-when-you-look-back/

Emacs 31 Is Around the Corner: The Changes I’m Already Daily Driving

Tags: tech, editor, emacs

Not CE features coming out of the box in the next Emacs release.

https://www.rahuljuliato.com/posts/emacs-31-around-the-corner

RFC 10008: The HTTP QUERY Method

Tags: tech, http, standard

Looks like we’re getting a new HTTP method. This should help remove ambiguous POST calls when really what you want is to query. This is long overdue, let’s hope this new QUERY method sees quick adoption in servers, frameworks and services.

https://www.rfc-editor.org/info/rfc10008/

What can wonky APIs tell us about the web?

Tags: tech, web, api, maintenance

Designing APIs for the Web platform is hard and error-prone. This is why it carries baggage, here is a good example.

https://alexwlchan.net/2026/wonky-web-apis/

Configuration is a liability, just like code

Tags: tech, system, config, complexity, maintenance

Indeed, we try to limit the amount of code we need to maintain. But configuration can bring its own complexity and maintenance burden as well.

https://utcc.utoronto.ca/~cks/space/blog/sysadmin/ConfigurationIsALiability

Improvements to std::format in C++26

Tags: tech, c++

Those improvements are welcome. I wish we’d see more std::format uses.

https://mariusbancila.ro/blog/2026/06/19/improvements-to-stdformat-in-c26/

Rewriting the world in Rust

Tags: tech, rust, architecture

Friendly reminder that the answer is “no”. You don’t want to just rewrite everything, it’s not just a syntactical translation, it’s a long project and at best you tackle critical components.

https://bitfieldconsulting.com/posts/rewrite-in-rust

Project Valhalla, Explained: How a Decade of Work Arrives in JDK 28

Tags: tech, java, type-systems, memory, performance

This is just the beginning in a way, but it’ll be a game changer for Java. The value classes will allow for better memory density.

https://www.jvm-weekly.com/p/project-valhalla-explained-how-a

Stop Naming Your Variables “Flag”: The Art of Boolean Prefixes

Tags: tech, programming, maintenance

Good advice on naming booleans. It’s worth repeating.

https://thatamazingprogrammer.com/posts/stop-naming-your-variables-flag-the-art-of-boolean-prefixes/

How to Write an Effective Software Design Document

Tags: tech, design, architecture, documentation, engineering

This is a good reference on how to write design documents. It’s not as easy as it sounds sometimes, and this guide contains good tips.

https://refactoringenglish.com/excerpts/write-an-effective-design-doc/

How to stand against high temperatures

Tags: life, climate

Obviously good advice and things we need to internalize now. Structural change is needed of course, but when the heat is here, better act properly.

https://www.whateverthewindbrings.com/how-to-stand-against-high-temperatures/

Bye for now!

This year, there was another display next hackfest, this time in Nice, France. This was a very productive hackfest, so I’ll focus just on my personal highlights here.

KMS backlight property

As mentioned in the blog post about the last hackfest, the current backlight API on Linux is a total mess. To remind you, the kernel exposes backlight devices through sysfs, which has several problems:

• this API doesn’t tell you which display the backlight is for. Effectively, only one backlight is supported
• some of the backlight devices don’t actually work, it’s up to userspace to figure out which one to use
• you need root privileges to change the backlight brightness
• there’s no proper minimum. On some displays, backlight level zero turns the backlight off, on others that’s the minimum brightness. In some cases, non-zero but very low levels result in wrong colors
• there’s no information on how long it takes to apply brightness changes

The new KMS API adds a backlight property to connectors of built-in panels (external monitors may be supported later), so the compositor knows exactly which display it’s for, and it can change the backlight without needing more permissions than it already has for driving the display.

We talked about the requirements to merge the API, concluded that it’s okay to leave it at one unit-less value for now (it can be trivially extended later), wrote and tested implementations and it’s pretty much ready to be merged.

KMS colorops

KMS colorops allow the compositor to offload some color operations to the scanout hardware, which can save a lot of power. We discussed how to best extend it to support YCbCr buffers, which are required for efficient video playback, and tested an implementation of the addition in amdgpu.

The implementation had some bugs with interesting visual results, but we debugged that and could find the source of the problem. The API for this should be merged sooner than later as well.

Scheduling Atomic Commits

As another follow-up to last year’s hackfest, we now had an implementation for what we agreed on last year:

• 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

We also talked about how all of this should work with ultra high refresh rate monitors, since CPU schedulers are quite bad at timing things precisely. To put things into perspective: KWin currently sets the target commit time to 1ms before vblank, since schedulers sometimes wake up KWin’s thread hundreds of microseconds later than planned.

With a 1000Hz display, the compositor would only have 1ms to commit each frame, so that doesn’t exactly work out well. Worst case, the compositor may need to immediately commit the next frame once the last one is finished, but in an ideal world, the kernel would ‘just’ be able to schedule the compositor’s threads more accurately.

VRR and QMS

Variable refresh rate has a few annoying problems right now:

• when the refresh rate changes too quickly, many displays change in brightness, which is visible as flickering
• HDMI doesn’t require displays to make switching between VRR on and off seamless, so many TVs go blank for a second when doing this
• compositors currently don’t have any (good) way to set an exact refresh rate without turning VRR off

All of these issues can be solved by allowing the compositor to set a minimum and maximum refresh rate that the display needs to stay between. We had two proposals for this:

1. allow compositors to set a minimum and maximum refresh duration in nanoseconds
2. allow compositors to set a minimum and maximum refresh rate with a numerator and denominator for both rates

For compositors, the first one is generally simpler, but the second one is needed for HDMI’s QMS feature. The “Quick Media Switching” functionality makes TVs switch to exact video refresh rates, which are specified as a numerator and denominator rather than a duration.

We still need more implementations for this to move ahead, but the direction to go in seemed pretty clear.

Color formats and BPC

Currently on Linux, if you want to configure how the image is sent to your display, you’re out of luck. Both the bit depth (how many bits per color are used) and the color format (RGB vs. YCbCr, chroma subsampling) can’t be configured, the driver chooses both automatically.

The new color format KMS property will solve this problem for the color format side, and we discussed how to do the same for bit depth. We concluded that a “min bpc” to match the already existing “max bpc” would likely be the best way to do this, since compositors can either choose a specific bpc that way, or leave it up to the driver to pick the best possible value.

FreeSync HDR, HDR10+, HDMI SBTM

Anyone that’s used HDR for some time knows that displays basically never do it right. Their tonemapping behavior can be unpredictable, and especially TVs often do a lot of “interesting” things in an attempt to improve the image, which can have very bad effects on PCs and video games.

For example, my TV by default makes images brighter than they are. If I use the brightness slider in Plasma, the TV literally compensates the reduced brightness away!

FreeSync HDR is one way to solve this problem: Instead of sending a signal to the screen that’s way larger than required (BT.2020 + PQ), just give the display an image in its native colorspace (native primaries + gamma 2.2 with 1.0 being the maximum luminance), and ensure it does the absolute minimum amount of tonemapping possible.

While TVs sadly don’t usually support this mode, a lot of higher end gaming monitors do, and as it turns out, supporting it on Linux wasn’t actually all that difficult - I already have a kernel patchset to enable the functionality that happened to be mostly there in amdgpu already, and on the compositor side it was entirely trivial. The only part that’s still missing is parsing the relevant bits from the monitor’s EDID to figure out if it actually supports that mode.

Specifications for the FreeSync information in the EDID are unfortunately not public (yet?), so we’ll have to reverse-engineer it. Luckily, some people have already gotten most of the way there, we just need to implement it in libdisplay-info and verify its correctness with a bunch of screens.

HDR10+ and HDMI Source-Based Tone Mapping are other standards intended to solve similar problems, and we’d really like drivers to implement them as well.

Atomic commit feedback

There was some discussion on how compositors can get feedback on why a particular atomic commit failed. There are two big cases where this is important:

• when trying to change the display configuration, especially enabling displays for the first time
• when trying to find the optimal setup for overlay planes¹

Currently, graphics drivers effectively just say “no” when something doesn’t work, and both compositors and users are left to try random things until hopefully some configuration is usable.

There’s an existing patchset to provide such information, which is very useful for display configuration, but less useful for overlay planes. We talked a bit about how this could possibly be improved, how the API might be extended in the future, and whether or not a userspace library that’s more aware of vendor-specific hardware (and driver) limitations might be a better approach for improving overlay plane usage.

linux-dmabuf version 6

This latest version of the linux-dmabuf protocol allows the compositor to advertise that it supports multiple GPUs, and allows applications to set which GPUs they’re using. I’ll make a separate blog post about this, but the important bit is that it allows for performance improvements in many systems with multiple graphics cards. This is quite the extreme case, but on my setup with an external GPU, using this protocol in Mesa and KWin literally improves performance in Cyberpunk 2077 by 100%!

After some explanation of how it works and minor adjustments to the protocol text, we merged it. There’s even a wayland-protocol release for it now!

Non-blocking modeset commits

The KMS API has some annoying quirks, and one of them is how you request an event for images being presented. You can request these page-flip events with a flag on each atomic commit, but if you try to present to multiple CRTCs (usually one per screen) at the same time, you get one event per CRTC.

That part by itself is fine, but what’s more problematic is that the kernel has a pretty old workaround for some old and buggy compositor: It doesn’t allow you to request page-flip events if any of the CRTCs in an atomic commit are actually turned off.

Because of this, for changing the display configuration, KWin currently uses a blocking commit, which can take up to 90ms in my testing (with a single screen) and blocks KWin’s main thread for that time. At the hackfest, Simon put together a kernel patch for allowing compositors to request a page-flip event per CRTC instead of globally, which solves this problem very nicely.

Switching between compositors

When you switch between compositors, currently the compositor you switch to gets all the KMS state from the compositor you switched away from. This can be very convenient for smooth transitions, for example when logging in from the Plasma login manager to the Plasma Wayland session, but it can also go wrong, for example when logging in from the Plasma login manager with HDR enabled into an Xorg session that doesn’t understand HDR at all.

This problem has existed since the day KMS was created, and there was never a good solution for it. Some compositors “clean up” after themselves before you switch virtual terminals, but that workaround prevents those smooth transitions and it’s not a fully robust way of fixing this.

We looked into finally fixing this properly, and concluded that we want a flag in an atomic commit that makes the kernel reset everything to some sane default state before applying it. This way, we can get more reliable switching between compositors without having to compromise on smooth transitions where possible.

Driver bugs

When doing bug triage for KWin, I usually spend a significant amount of time telling our users that their problems are caused by bugs in graphics drivers and where to report them. So I’m especially happy to hear about important problems being solved:

• the likely by far biggest source of page-flip timeouts on AMD GPUs is finally getting fixed. This was especially bad on AMD laptops, where leaving PSR² enabled could trigger such a freeze multiple times each week
• a Nvidia driver bug causing freezes when using overlay planes is getting fixed
• slow atomic commits on AMD are getting improved. I wrote a KWin autotest that consistently triggers the issue at the hackfest, and Harry made a fix for the most severe cases since then. On my laptop the stutter caused by it isn’t usually noticeable, but on dedicated GPUs it was pretty bad

More than just being very annoying, these specific issues are also the blockers for enabling overlay planes by default in KWin on the respective hardware. I have high hopes that we can finally enable overlay planes by default on all hardware this year!

Conclusion

I’m really glad to see so much progress on these topics. My nearly infinite wishlist for driver changes is actually shrinking for once!

Thank you to Collabora for organizing and sponsoring the event, and thanks to all the awesome people for being there and making things happen :)

For those who are not yet familiar with the new Qt Canvas Painter, please check the previous blog posts: Introduction, new features, and performance measurements. This blog post introduces paths and path groups to further improve the performance.