Update on what happened across the GNOME project in the weekOctober 9 to October 16.

Miscellaneous

balooii reports

After the initial summer release of Contributor Atlas I can now announce the next version and additional dataset. This release now supports multi-project communities, a lot of polish and a few visualization which are either fun or insightful. Hopefully both. The new dataset is the GNOME community with many of its projects and their contributors. Have fun exploring over at https://balooii.pages.gitlab.gnome.org/contributor-atlas/

GNOME OS ↗

The GNOME operating system, development and testing platform

Ada Magicat announces

We are excited to announce GNOME OS Preview!

This new edition of GNOME OS is builtthe latest stable release of GNOME, unlike our nightly edition.

Targetted at early adopters, it should provide a much more reliable experience.

More details on Adrian’s blog: https://blogs.gnome.org/adrianvovk/2026/10/16/gnome-os-preview/

Downloads at the usual place: https://os.gnome.org

GNOME Core Apps and Libraries

Libadwaita ↗

Building blocks for modern GNOME apps using GTK4.

Alice (she/her) 🏳️‍⚧️🏳️‍🌈 announces

AdwActionRow now has the :body property, allowing to add single full width child, like a slider, illustration or a toggle group

Calendar ↗

A simple calendar application.

Zelda Ahmed 🏳️‍⚧️ 🐀💙💜🩷 reports

GNOME Calendar Highlights of the Week

This week we had quite a few nice improvements land to Calendar this week, including a lot of clean-up and back-end improvements, and a few user facing changes. Thank you to all the amazing community members for their efforts to make Calendar even better this week!

Decrementing and Incrementing Years in the Month Spin Button

In the month spin button, going to the previous monthJanuary will now jump to December of the previous year. Similarly, going to the next monthDecember will jump to January next year.

This had been a long requested feature for quite a while. It seemed easy to implement, but it ended up being more difficult than desired. Since Calendar has several views, many of the widgets’ properties are shared. When one of the widgets changes, every widget updates accordingly, which made it difficult to have the years and months changing at the same time. This required building on top of the optimisations made to the date chooser that landed a few weeks ago.

See !853, by Hari Rana

Zoom Shortcuts

To make it easier to control Calendar using just keyboard shortcuts, we added the ability to use Ctrl+/Ctrl- to zoom in and out of the week view. This joins the ability to zoom in and out the week view using a trackpad or holding down Ctrl and scrolling the mouse wheel.

See !859, by Arak

Configurable Month Rows

The month view in Calendar is split into rows, with each row representing a week in a given month. The number of rows in the month view was hardcoded to 5 to span all the weeks in one month. While this works for most people, for users with non-standard display sizes or busier schedules, a hardcoded 5 rows was too limiting.

The first steps to make the month view more flexible landed this week, with the ability to change the number of rows displayed in the month view. This feature is still experimental, currently requiring the user to change the value through an internal setting using a program like dconf editor, but exposing this option in the user interface is planned for later this cycle.

See !856, by Georges Stavracas

Third Party Projects

xjuan announces

Cambalache 1.2 Released!

Hello, I am pleased to announce a new stable release.

Cambalache is a WYSIWYG (What You See Is What You Get) tool that allows you to create and edit user interfaces for @GTK 4 and 3 applications.

This new version depends on @gnome SDK 51 and includes all new properties and typesGtk and Adwaita! It also removes the file hashthe project file which should prevent unnecessary git conflicts.

https://blogs.gnome.org/xjuan/2026/10/14/cambalache-1-2-released/

Jan-Willem reports

This week I released Haystack, a new GNOME app for editing OpenQA needles. OpenQA is an automated test tool for operating systems, and it uses needles (annotated screenshots) to verify the output. Haystack makes it easy and convenient to create and maintain needles.

Get it on Flathub

Haydn Trowell reports

Typesetter, the Typst editor for focused writing, gets its biggest update yet with version 0.16.

The headline feature is sandbox-compatible multi-file projects. Typesetter now uses a new default archive-based project format, .typz, that keeps your document and everything it references (images, imports, and other assets) together in a single file. Projects work the same wherever you open them, and they’re easy to share and back up. Because Typesetter now only ever needs access to the files you explicitly open, never entire folders, multi-file Typst projects now work easily and reliably within the Flatpak sandbox.

A project can hold as many sub-files as you like, so you can split a long document into chapters or sections, keep reusable functions and styles in their own files, and bring everything together with #include and #import statements.

This replaces the previous “project folder” workflow, which was required to make imported files available to single-file .typ documents. That approach presupposed access to whole directories, which the sandbox is designed to prevent, and it was easy to get wrong. Removing it means there is now one secure, consistent way to include files in a document.

Typesetter can still open and edit standalone .typ documents, but they can no longer reference external files. To include assets in an existing document, open it and choose “Save As Project” when prompted, then add the files through the navigator.

Other noteworthy features include:

• GUI bibliography manager: You can now add and edit references through a dedicated graphical interface.
• Adjustable preview pane: The preview pane can now be manually resized to suit your workflow.
• Comments navigator: A new navigator lets you list, view, and jump directly to author comments throughout your document.
• New templates: Typesetter now includes several additional templates to help you get started with new documents. (More to come.)

Since the previous release announcement, Typesetter has also gained advanced export to HTML and Markdown, making it easier to share documents in other formats.

There have also been a range of performance improvements, bug fixes, and smaller feature updates across the application, continuing Typesetter’s focus on being a fast, distraction-free writing environment.

Typesetter 0.16.0 is available now on Flathub.

Riyan announces

Kaori an open-source comic reader for GNOME, which allows you to discover, download and read comics with a beautiful libadwaita UI and natural touchpad gestures.

The name Kaori is a small tribute to Kaori MiyazonoYour Lie in April, a character who left a lasting impression on me.

Kaori is now available on Flathub

Haydn Trowell reports

A new update to Kotoba, the Japanese–English dictionary app, is live on Flathub. This release includes some code cleanup, internal optimizations, and an upgrade to the GNOME 51 runtime.

Grab it here: https://flathub.org/apps/net.trowell.kotoba

moosee says

Moose — A native GTK and libadwaita app for local and cloud AI chats

Moose 0.6.0 is out! I started Moose to give local AI a comfortable home on the Linux desktop. This release brings cloud models into the app while making it clearer what you share and where it goes. Connect to Ollama Cloud, Groq, OpenAI, Anthropic, or Google Gemini with your own API key, stored in your desktop keyring. When you want to keep inference on your device, Local Only restricts it to Ollama managed by Moose.

For remote providers, choose whether Moose asks before sharing messages in each chat or remembers your choice across chats with that provider. Files have a separate permission. You can review the context before it is sent and reset permissions in Privacy settings.

I’m especially happy with the new Files view. It gives attachments and library documents a place of their own: search and filter them, preview a file, find its original folder, return to a related chat, or attach it to the current conversation. There’s also a broader local model catalog for chat, vision, reasoning, and coding. Waiting and reasoning indicators are clearer, and remote Ollama connections now require HTTPS.

Conversations, drafts, and the document library stay on your device. Content you choose to share with a remote provider is handled under that provider’s data policy. If you give Moose a try, I’d love to hear what you think.

• Get it on Flathub: https://flathub.org/en/apps/io.github.moooossee.Moose
• Source code: https://github.com/moooossee/moose
• Project website: https://moooossee.github.io/
• Release notes: https://github.com/moooossee/moose/releases/tag/v0.6.0

Lockpicker ↗

Recover passwordstheir hash

Sjoerd Stendahl says

This week I had a design discussion with Philipp Sauberzweig about Lockpicker. Before making some bigger changes, I decided to start with the low-hanging fruit. So this release mainly focuses on minor adjustments and some bug-fixes that were already in the main branch of the code. The biggest visible changes are a hash picker that includes the custom modules, the ability to select/unselect rules by drag and drop, and the proper use of Adw Comborows throughout the application instead of the old Gtk pickers.

Lockpicker is a tool to help you to recover passwords based on a hash, it’s essentially a GUI front-end to hashcat. You can get it on Flathub here.

Gitte ↗

A simple Git GUI for GNOME

Christian says

Gitte, a simple Git client for GNOME built with GTK4, libadwaita and Relm4, just got its 0.11.0 release! 🎉

The headline feature this time is search in the commit graph: you can now find commits directly in the graph using the same search syntax as the commit log. Search also learned to match commit IDs and ID prefixes (short IDs), and author searches now match email addresses as well as names. And with the new sidebar search (Ctrl+K), you can quickly filter branches, tags and remote branches.

Commit messages got a few new tools, too. You can add trailers using configurable templates, set defaults per repository, and sign off commits with your identity. When squashing commits, trailers are merged, and edited commit messages are preserved when a history rewrite pauses. There is also a new button in the commit details to copy the complete message.

Amending a commit is now much more flexible: you can edit all changesthe previous commit, including unstaging changes to remove themthat commit.

A few more things can now be tailored to your repositories. You can choose whether they open in Changes, Current Branch or Commit Graph, either globally or per repository. Gitte also picks up a logo.png in the repository root, following the project-logo convention used by GNOME. logo.gif, logo.jpg and logo.jpeg are supported, too.

On the UI side, selection handling in the working copy and stashes views is smoother, with selections restored after refreshes and filtering. The repository name now shows up when the sidebar is collapsed, preferences tabs and repository settings have been reorganised, and spacing, compact-mode padding, diff icons and layouts with long translations got some polish.

And of course there is the usual pile of fixes: discarding hunks or selected lines during a rebase no longer runs into hunk-index errors, file names containing wildcard characters are handled correctly, and conflict diffs are loaded against HEAD. Status errors are now reported instead of making the working copy look empty, and diffs use consistent path prefixes regardless of your Git configuration. Failed clone attempts no longer risk deleting an existing destination folder, rebases resume correctly when commit signing is enabled, and notification messages display characters such as < and & correctly. macOS also got more reliable detection of command-line tools.

Under the hood there are updated German and Ukrainian translations, fresh dependencies and bundled Git and Git LFS versions, and a move to the GNOME 51 Flatpak runtime.

Get it on Flathub, for macOS or have a look at the Code.

Bouncer ↗

Bouncer is an application to help you choose the correct firewall zone for wireless connections.

justinrdonnelly announces

Bouncer 51 is out! It may be fall here, but it was time for some spring cleaning. This release includes a bunch of small cleanups. The most siginificant user-facing change is the upgrade to GNOME 51. Get itFlathub. I hope you enjoy it!

Shell Extensions

Just Perfection reports

We are calling for volunteers to help the GNOME Extensions team with code reviews and Shexli linter improvements. If you are interested in joining the review team or helping with Shexli, please reach out to us in the GNOME Extensions Matrix channel.

Just Perfection says

A new rule has been added to the EGO review guidelines that makes the GJS shebang mandatory for all standalone GJS scripts.

This rule was introduced because standalone GJS files have a different architecture than standard modules. They run the mainloop in the global scope, which should never be done by extensions in a shell process. To make it clear during code review that these files are standalone scripts rather than modules loaded into the shell process, they must start with the GJS shebang.

swink announces

Now Playing Card got a few more updates since last time.

Beautiful music controls for the top bar: a minimal animated indicator and a compact card with cover art, a seek bar and playback controls, for any MPRIS player.

After the last post, many people sent in feature requests, and a lot of them are now in. Thanks to everyone who wrote in!

Recent updates bring:

• a new icon (grey hills in fog) and a matching spectrum shape, Waves, where the hills drift by and rise with the sound
• an optional “Follow all sound” mode: the spectrum reacts to any sound on the system, including calls and games, not only the player
• a lighter panel icon that runs on its own timer instead of the frame clock, with a frames-per-second setting (10–60)
• an option to show the playing app’s icon in the panel, next to the equalizer or in its place
• album art can be turned off, so nothing is fetchedthe web
• equalizer bars can use the system accent colour (GNOME 47 and later)
• right click on the panel button can play/pause or skip instead of opening the menu
• wide video thumbnails fill the cover square instead of being squeezed
• a reset-all-settings button on the About page

Source code is on GitHub.

That’s all for this week!

See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!

It’s been two years since my initial post about making GNOME OS an end-user general purpose OS. Today, we’re excited to announce that we’ve hit a major milestone!

TL;DR: We’re launching a new edition called “GNOME OS Preview”, which is built from the latest stable GNOME release. This means that GNOME OS is no longer just a nightly OS for GNOME developers and testers!

The Road to Stable

Even though GNOME OS has been usable on real hardware for a few years now, its appeal was limited. We’ve only had the Nightly edition, which is constantly rebuilt to ship the latest git commit of every GNOME component (and a few others, like systemd and Flatpak). This form of GNOME OS is extremely useful, since GNOME developers and designers can daily-drive it to test the latest changes. However, it’s not something we’d recommend to non-developers.

Over the past year, we’ve seen a lot of adoption of GNOME OS Nightly amongst GNOME developers, especially following the success of last year’s Summer of GNOME OS challenge. This has led to a significant uptick in contributions and initiatives aimed at improving user and developer experience. For instance:

• Thanks to Jonas Dreßler’s, Valentin David’s, and Sebastian Wick’s zswap enablement efforts, GNOME OS now handles devices with limited amounts of RAM without OOM stalls. Jonas also found a hack that lets GNOME OS dynamically grow the usable on-disk swap space on-demand, which makes zswap perform significantly better than usual.
• The recently released Test Center app allows you to install CI builds of Flatpak apps from a merge request, making it super easy to test experimental changes before they are even merged. On GNOME OS Nightly, Test Center can do the same with system components by applying them as a system extension.
• Jordan Petridis’s new Toolpak project aims to provide a clean solution for distributing and installing command-line applications that developers need in a cross-distro fashion, similarly to how Flatpak and Flathub work for graphical apps.

Of course, long-term our goal is an OS for the broader public. We’re working on this across a number of different fronts, including:

• Enablement for systemd-homed across the stack, allowing for stronger per-user disk encryption and other benefits.
• Experimental work in the kernel to solve a bunch of limitations we’ve run into with filesystems. Ada Magicat went on a deep dive on her recent All Systems Go talk!
• Deep integration between systemd-homed and the session’s keyring, to increase security of the session’s lock screen. Dhanuka Warusadura gave a lightning talk at All Systems Go about his work on this.
• A new feature-complete installer, to replace the current placeholder installer. Julian Sparber also gave a talk about this at All Systems Go, with a live demo!
• Support for delta updates in systemd-sysupdate, to avoid downloading a full 2 GB image every time.
• Better integration with the TPM, including a graphical TPM recovery UI. Currently, trying to type a TPM recovery key into Plymouth is rather difficult.
• Improved support for ARM hardware, including some specific models of phones. Abderrahim Kitouni gave a lightning talk at GUADEC this year about the current installation process.
• Shipping our pre-installed apps as Flatpaks, and reworking the app release process to unify the build definitions between GNOME OS, the GNOME Nightly Apps Flatpak repo, and Flathub.
• An STF project focused on Flatpak and Portals, which will enable broader app support on GNOME OS (like VPNs!). You can learn more from the announcement blog post.

Some of these areas require lots more work before they’re ready for prime time, and even once they’re ready it’s not clear that it’ll be possible to migrate existing GNOME OS installations to use these new features. At FOSDEM this year, we discussed this issue and decided that we won’t declare GNOME OS as “stable” until we can confidently commit to maintaining a clear long-term upgrade path for existing installations.

However, we also don’t think that all these things need to be in place before GNOME OS can be used by more people than it is today. It’s not ready for the masses yet, but it is ready for early adopters that aren’t quite adventerous enough to run a nightly OS.

Introducing GNOME OS Preview

GNOME OS Preview is the current GNOME OS Nightly, but without the “nightly” aspect. Instead, it’s built from the latest stable GNOME release (GNOME 51.1, at the time of writing). GNOME OS Preview lives in the same branches on GitLab as the stable org.gnome.Platform Flatpak runtimes.

GNOME OS Preview is only a few weeks old, so it has only seen limited real-life testing so far. We therefore expect people will uncover some issues initially. That said, Preview is significantly more stable than Nightly, which dozens of people have been daily driving without major issues for over a year. Thus, we’re feeling confident that Preview is going to be reliable enough for daily use by non-developer enthusiasts.

In all likelihood, GNOME OS Preview will be with us for a few years. However, we are explicitly not promising updates in perpetuity. If you’re not OK with re-installing your OS in a few years to switch to GNOME OS Stable, this is not for you yet. But if you’ve already been curious about giving GNOME OS a try, this is the moment!

GNOME OS Preview is available for download on the newly-refreshed os.gnome.org! GNOME OS Nightly is still available from there too. As always, you can reach us on Matrix at #gnome-os:gnome.org or via the gnome-os tag on Discourse

Epic just announced the upcoming version 2 of their Linux implementation of Easy Anti-Cheat. It’s based on using the Linux eBPF security module to monitor what’s happening, and then a bunch of extra infrastructure to make sure this can’t be bypassed. The core part of this is requiring secure boot be enabled (ensuring that modified kernels can’t be used), using measured boot to verify that secure boot is enabled and which keys are used (to prevent you from just signing your own modified kernel), and then doing remote attestation, a mechanism where the TPM generates a signed copy of the boot measurements and passes that off to a server which verifies it came from a real TPM, verifies that you have secure boot enabled and are using the right keys, and presumably then allows you into the game.

This is all fine as long as you can prove that the measurements provided are real, and that’s actually a lot harder than you might think. First, we can simply make up our own quote signed with our own key and say that it came from a TPM. This is avoided by every TPM having an Endorsement Key (or EK) and an associated certificate, with that certificate being signed by the TPM vendor. If you have a list of all the legitimate TPM vendors and their CA keys, you can verify that the measurements came from a real TPM. Easy enough. So we need to get the measurements from a real TPM, and the one on our motherboard contains the measurements that were generated by the firmware and bootloader, and we can’t reset those at runtime without resetting the TPM, which… oh huh there’s actually nothing stopping us from doing that at runtime, as long as we have access to the hardware. Many desktop boards have the TPM on a small plugin module with a standard pinout that includes a reset pin. Simply short that to ground briefly and the TPM is back in its initial state, and userland can write whatever measurements it wants to it. Boot a modified kernel which lies to the eBPF code? As long as you replay the expected log values from a boot with secure boot on and a trusted kernel, the TPM will still happily provide a legitimate set of measurements that’ll satisfy the checker.

What if the TPM is less accessible, either because it’s mounted directly to the motherboard or it’s inside the CPU or chipset? That’s going to be trickier. But here’s the thing. The quote needs to come from a TPM, but not necessarily the TPM on your motherboard. TPMs these days are usually connected via the Serial Peripheral Interface, usually referred to as SPI. Microchip make a USB to SPI bridge, and there’s a Linux driver. Wire one of those up with an appropriate header and you can plug in an easily available TPM module intended for plugging into a motherboard, and now we tell the kernel to ignore the motherboard TPM and make /dev/tpmrm0 point at the USB one and program it with a set of trusted measurements and once again everything is going to look just fine (yes obviously the eBPF code can look for this, but we’re running a modified kernel so we can just lie to the eBPF code).

Remote attestation on PCs just doesn’t work that well in environments where you can’t associate a specific TPM with a specific system, which is basically everywhere except enterprises. But maybe that doesn’t matter and cheaters wouldn’t be willing to spend the $20 or so it’d take to produce one of these things? That would seem somewhat surprising, but it’s not impossible. And obviously any server-side cheat detection that triggers could then block that specific TPM, meaning they’d need to go and get another TPM, and maybe that ends up being enough to discourage people from bothering. From a practical level, this may be sufficient. But at a technical level? It’s not great.

One of my favourite things in the Python standard library is the ThreadPoolExecutor. It is a very simple way to run a bunch of tasks in parallel, such as converting or repacking a whole bunch of image files from one format to another. You write a pure function that takes two arguments, the input and output file names, and does the conversion. Then you submit a bunch of tasks (basically function and argument pairs) and the executor runs them with maximal parallelism.

I decided to implement this in Pystd. To make things simpler it does not yet support futures for return values. Writing a thread pool executor needs some fundamental building blocks such as threads, mutexes and condition variables. Once those were implemented (and working), writing the actual "business logic" turned out to be fairly simple. In fact, it took less time than writing the PNG processing code with libpng.

First you need to write this helper class to register you task for running. It also stores all arguments etc that the task needs to do its thing. Yes, this has a bit of that "icky 90s Java" feeling to it but OTOH it is fairly simple, has unambiguous ownership semantics and compiles massively faster than your typical template monstrosity.

Using this is just a matter of globbing for png files in the input dir and submitting tasks for them.

The UX is a bit verbose. It could probably be made nicer with a helper method or two. Still, not too shabby for something written by hand in a single afternoon.

For those interested in details, the code for this program is in the pngtest branch.

After my mother passed away I ended up with a big box full of old film negatives containing photos from childhood family trips and similar. So I decided to buy a negative photo scanner and found that the Plustek 8200i was supported under Linux so I bought that. Only to discover that the chipset in the scanner had changed to one that wasn’t supported under Linux anymore. So I had some success making Linux configuration tools for some of my hardware using Claude code, like my Dell Camera controller app so I thought, maybe Claude can help me get a working SANE driver. I basically got stuck and got nowhere for the longest time and even basically gave up on the project for a few Months.

Then I saw a post on X from Tom Crider aka Glorious Eggroll talking about how he had managed to fix a mouse driver using AI tooling. He basically described how he set it up so that the AI agent had full control of a Windows instance to capture data needed to fix the driver. So I pasted his tweet into Claude and asked it to help me set up a windows virtual machine to do the same things Tom as doing for my scanner. I think the combination of having the ability to run scans under windows and capture the USB data while doing so worked wonders, probably combined with improvements to Claude code made a huge difference. Within a few hours I had my first ever working scan under Linux, sure with some quality issues, but 100% recognizable as the image in the negative. Some days later I had a near perfect driver, including support for Infrared scanning ready to go, only to discover that in the time between me giving up and then trying again someone had committed code to SANE to support the scanner already…..it happens sometimes. I also used Claude to write an application for doing negative scanning, which I named Negative Vibes, thought that was a cute name.

Anyway, with the success of my scanner effort I thought, I wonder if I can use this to finally fix the last issues with MIPI camera support on my laptop. So I told claude to re-use the harness I had created and try to fix the MIPI camera on my laptop by updating the kernel driver and libcamera as needed. I started the job in the morning and by the end of the day I had a much improved situation with patches for both the kernel and libcamera ready.

So I thought that this might be worthwhile sharing with the world, and while anyone could start from scratch I did ask Claude to make the harness generic and document it to make the pathway for anyone else who wants to try this on their hardware a little easier. Writing a driver for undocumented hardware has always been tedious. You capture bus traffic, stare at hex dumps, and form hypotheses about what each register or control transfer does. You then test them one at a time, usually for weeks. None of it is conceptually hard, but it takes a lot of patience and skills.

That kind of work suits an AI model well. It can read thousands of lines of USB capture, notice that a sequence repeats with one byte changing, and propose what that byte means. It can write the test to confirm it, and it doesn’t get bored. The human still decides what to build and checks that it works on real hardware, but the slog shrinks a lot.

hw-harness

Be aware that I did not use hw-harness in this form for my projects as this was basically bespoke code at that time, so this project is an attempt to make the harness more generic and shareable from the scripts I was using while doing the work. What hw-harness is meant to help your Claude or Codex session with:

1. Record a reference session. Run the vendor’s Windows driver in a KVM virtual machine, with the real device passed through to the guest.
2. Capture from outside the VM. Record the traffic on the Linux host with usbmon. It sits below the passthrough layer, so the guest can’t see it.
3. Repeat the same operation on Linux with your own driver, and capture that the same way.
4. Diff the two traces. Both come from the same instrument, so they compare directly. The differences are your list of driver bugs.

For devices with no bus to tap, such as an internal MIPI camera, the harness uses Windows-side inspection instead. That means INF files, registry data, ACPI tables and device properties.

The approach should be fine in the sense it doesn’t rely on copying any code instead it observes what the hardware does and only extract configuration data from the Windows drivers, so every constant in the new driver traces back to something recorded.

So for those interested I have 3 short descriptions of the projects I did and what was needed.

Project 1: a SANE backend for the Plustek OpticFilm 8200i

The first project is a SANE backend for the newer Plustek OpticFilm 8200i. It uses the Genesys GL128 controller (USB 07b3:1825) and had no Linux support. The older model with the same name uses a GL845 and is already handled by SANE.

The backend supports:

• Color, gray, infrared and color+infrared modes
• Resolutions from 300 to 7200 dpi, at 8 or 16 bits per channel
• Dust and scratch removal from the infrared channel
• An exposure multiplier for dense negatives

It’s packaged as a Fedora RPM, built automatically on every push. I mostly tested it with my own Negative Vibes application as there are not that many options under Linux for negative scanning.

Upstream SANE’s genesys backend also gained support for this scanner in September 2026, so I compared the two. Both resolve the same fine detail at 3600 dpi. Mine is faster at full resolution (34.6 s against 54.4 s) and supports infrared dust removal. Upstream offers more resolution steps. The webpage has an interactive side-by-side comparison you can check out. These are single-unit, single-frame results, so treat them as one data point. Check out the interactive page I made showing the current state of the two drivers, hopefully the discoveries I made can be used by the SANE project to fix some smaller items in the upstream driver. Anyway, I put this project up more as a proof of concept due to that since I expect everyone including myself will use the upstream driver once it reaches parity with this one.

Project 2: Negative Vibes

A driver alone isn’t much use if scanning negatives is still painful, so I built Negative Vibes. It’s a GNOME app, written in Rust, for scanning colour and black-and-white negatives and slides on any film-capable SANE scanner.

The scan is kept exactly as the scanner delivered it: 16-bit, linear, with the infrared plane. Everything else is a stack of non-destructive settings on top, so you can change the look and export again. It includes:

• Density-space negative inversion with film base and dye-crosstalk correction
• Roll-wide settings with per-frame overrides
• Infrared and software dust removal
• IT8 calibration through ArgyllCMS
• Export to TIFF, JPEG, PNG and DNG, with ICC profiles and metadata

It ships as a Flatpak that includes the scanner backend. It’s tested on the 8200i so far. The goal is to support any film scanner SANE supports. For that, SANE needs a standard way to expose infrared channels, which it doesn’t have yet.

Project 3: Fixing the MIPI camera on my ThinkPad

The camera in my Lenovo ThinkPad X1 Carbon Gen 14 (Aura Edition) uses a Sony IMX471 sensor behind an Intel IPU7. On Linux it produced dark images with heavy vignetting and a strong yellow-green cast. mipi-fixes-x1-aura collects the fixes. It’s only relevant to this laptop, which is why it isn’t one of the bigger packaged projects, but I have already submitted the kernel patches to Kate Hsuan and the libcamera patches is being reviewed by Wim Taymans for submission to Libcamera.

Kernel (IMX471 driver):

• A crop-selection bug returned an error before storing the crop rectangle, so libcamera assumed the full pixel array.
• The test-pattern register was declared with the wrong width.
• The analogue gain cap was too low, which cost about 1.8 stops of sensitivity.

libcamera software ISP:

• Lens shading correction was missing entirely, leaving the corners about 2.7 stops darker.
• White-balance statistics were summed at the sensor’s native bit depth against an 8-bit black level. That skewed white balance, and the fix applies to any RAW10/RAW12 sensor.

In a controlled low-light test, frame brightness rose from 31.1 to 90.9. The red/green and blue/green ratios moved from 0.890 and 0.672 to 1.047 and 0.823, close to a USB webcam reference. Blue is still about 17% short in low light, which I put down to grey-world white balance. Fedora 44 RPMs are on the releases page.

What I learned

• Reference captures are a big step. Having the AI compare a known-good trace against a failing one turns a vague “it doesn’t work” into a concrete list of differences. For example for the MIPI camera having a USB camera also connected so Claude could compare the two captures was critical.
• The AI is good at the tedium. That covers decoding captures, writing probes and cross-checking constants. I still have to be the one holding the physical hardware.
• Real hardware is the only judge. Every claim above was checked on the actual scanner or laptop.

If you have hardware with no Linux driver, try hw-harness. Thanks again to Glorious Eggroll for the inspiration.

NOTE: I am not claiming that my scans or MIPI camera is perfect now, but the scanner gives me decent looking scans and the MIPI camera looks a lot better than before. So over time I am sure we be able to tweak and polish further, but I am happy that it allowed me to move the needle despite lacking the in-depth knowledge for this type of work.

—

The gedit text editor version 51 has been released!

A previous blog post, News, April-May 2026 already covers most of the changes.

A reminder that gedit is still alive and is available to install, as an alternative.

Progress has been made since May, but it's mostly under-the-hood changes, preparatory work to replace some internals and eventually make bigger visible changes to the application(s).

B2B Services

gedit is not only an application, there is a set of libgedit-* shared libraries underneath. This collection of re-usable code can be leveraged to create new products, and B2B services are possible.

This was another reminder, but it cannot hurt ;-)

The fact this movie tanked at the box office just makes the ride all the more enjoyable. I had a bad headache and had to call off the screening with a friend yesterday. Thursday is when the movies rotate in our part of the world where we use the un-American units, so I thought I'd missed yet another great cinematic experience. Luckily they still showed it in a small neighboring town, to the two of us and two other people, with an introduction by a charming young person.

I don't remember anything these days, but I clearly remember when I saw Dr. Strangelove in Amherst, NH, in 1993. I was completely taken by the humor, despite thinking I'd never enjoy an ancient movie like that. It's probably way longer between my viewing and today than it was between then and the actual production of it. I don't wanna check.

Anyhow, this is masterfully done cinema, and all four of us laughed out loud at the horrors we saw. Absolute must-see.

★★★★★

Usually I blog about new additions to the GNOME wallpapers after a release, to give some behind the scenes look on how they were produced. This time I'm asking for some feedback beforehand.

Pixels has shipped as a wallpaper before. The wallpaper landed back in 2021 and keeps getting refreshed as new Circle apps join the lineup, and 47 added LCD and LCD-rainbow, revealing the curator's pixelart kink.

The raw material is a side project years in the making — app icons redrawn as chunky pixels (Pixels, Mo' Pixels, Revert That Vector Nonsense!).

The idea and layout remains the same as the old wallpaper. This time that's more than two variants though. The old Adwaita default used to cycle morning, day and night variants through a slideshow. While we switched to the dark/light variants, the format is still understood today. Thus pixelart comes in not 2, not 3, but 9 color variants. And here's where I'd like your feedback. Do you like the focus on contrast and having the whole set with dark background colors? Should there be more bright colors in the mix? Do you think the grain goes against the spirit of the pixel art? Is the small grid too toned down with the depth fog?

As always, the Blender project files are available in wallpaper-assets if you want to poke at the node setup yourself:

As with any wallpaper, don't judge it based on a preview, regardless of how large you view it. Apply it, use it. The most straightforward way to test GNOME development is with GNOME OS. It ships pixels and all the other wallpapers.

On September 22 we released systemd v262 into the wild.

In the weeks leading up to that release (and since then) I have posted a series of serieses of posts to Mastodon about key new features in this release, under the #systemd262 hash tag. In case you aren't using Mastodon, but would like to read up, here's a list of all 35 posts:

• Post #1: Word List Based Hostname Patterns
• Post #2: Extended Attributes on Socket Inodes
• Post #3: Varlink Socket Tagging & varlinkctl list-sockets
• Post #4: Machine Tags from udev/hwdb
• Post #5: systemd-sysupdate's installdb
• Post #6: Signed systemd-report Reports
• Post #7: CLI Introspection via --introspect-cli
• Post #8: fscrypt v2 Support in systemd-homed
• Post #9: Read-Only ESP Support in systemd-boot/systemd-stub
• Post #10: Recovery Key Enrollment on First Boot & Varlink IPC for systemd-cryptenroll
• Post #11: Rogue TPM Protection for LUKS Enrollments
• Post #12: Encrypted + Verity Protected DDIs
• Post #13: FONT_SCALE= in /etc/vconsole.conf
• Post #14: Static, Single-Binary Service Manager Builds
• Post #15: Intel TDX CoCo Support in systemd-vmspawn
• Post #16: Varlink IPC for systemd-sysinstall
• Post #17: systemd-report as Varlink Service & New Metrics
• Post #18: Sessions as Inhibitors via pam_systemd's inhibit=
• Post #19: NvPCR Rework
• Post #20: bootctl link-auto
• Post #21: systemd-sysupdate Completion Hooks
• Post #22: /etc/clonetab
• Post #23: Atomically Enqueuing Multiple Jobs
• Post #24: Following the Journal via Varlink
• Post #25: Coredumps via the Kernel's New Socket Protocol
• Post #26: Hardware-Suggested systemd-sysupdate Features/Components
• Post #27: ActivatingConcurrencyMax=
• Post #28: Restarting/Reloading Units on confext/sysext Application
• Post #29: System Credentials for CoCo VMs in systemd-vmspawn
• Post #30: Persisting the TPM EK
• Post #31: systemd.firstboot=headless
• Post #32: RestartRandomizedDelaySec=
• Post #33: systemd.credentials_boot_policy=
• Post #34: systemctl kexec --kernel-cmdline-reuse
• Post #35: PCR Signature Policyrefs

I intend to do a similar series of serieses of posts for the next systemd release (v263), hence if you haven't left tech Twitter for Mastodon yet, now is the opportunity. My series for v263 will begin in a few weeks most likely, under the #systemd263 hash tag.

In case you are interested, here is the corresponding blog story for systemd v261, here for v260, here for v259, here for v258, here for v257, and here for v256.