This year was the fourth year in a row that a bunch of display driver and compositor developers met for the Display Next Hackfest , to discuss, present, and tackle issues related to displays, GPUs, and compositors. Thanks to Collabora (Robert Mader and Mark Fillion specifically) for continuing this tradition!

(Check out the 2025 edition )

This time we met in Nice, France, after Embedded Recipes and right next to the PipeWire and libcamera hackfests. I took the opportunity to have a chat with the PipeWire developers about Flatpak, Portals, and the direction we would like to take in regard to video and audio access. Arun Raghavan has a nice summary if you’re interested.

That also brings me to another point: I have mostly stopped working on compositor and color-related areas. It’s not because I lost interest, but rather that I took over Flatpak and Portals maintenance. That by itself was taking a big chunk of time, but then LLMs became good at finding security vulnerabilities and now this takes more time than I have.

Before the hackfest, I sat down for one week and hacked on Mutter (the GNOME Shell compositor) to create a prototype with all the changes I wanted to do but never found the time for:

• dropping colord
• configuring ICC profiles and white point via the display config
• splitting our color transformation code to provide a color pipeline
• offloading color transforms to the KMS color pipeline
• achieving color-accurate white point adjustment and night light

With the prototype done, I made my way to Nice, taking a sleeper train from Paris and waking up to the Côte d’Azur in the morning. Then I met with Robert in the botanic garden, where he used his deep cross-stack offloading knowledge to test a bunch of video playback scenarios.

Over the hackfest days we found some glitches in the AMD driver, which were promptly fixed by Harry Wentland. We also had some discussions on strategies to do KMS color pipeline offloading, which prompted some changes in the prototype, and now have something we can start upstreaming.

For the KMS color pipeline, we got a new fixed matrix operation for YCbCr to RGB conversion, and new named curves for important video playback cases. We talked about control over the color format on the cable (which has been merged by now), as well as control over the minimum BPC.

Another thing that we all got annoyed by was all the funky colors our in-kernel console became when our offloading worked a bit too well. We’ve wanted a reset mechanism for KMS for a few years now anyway, so we decided to prototype it and test it on Smithay. Proper patches are now on the mailing list thanks to Maxime Ripard.

Mario Limonciello managed to push out patches for backlight support via KMS before the hackfest – another thing we’ve wanted for years. We tested them on Mutter, and KWin added support for it as well.

Xaver Hugl showed that we can easily support AMD FreeSync Premium Pro, the worst name for a feature that is essentially Source-Based Tone Mapping (SBTM). We also got good news regarding SBTM on HDMI. In general, it looks like we might finally get HDR that isn’t entirely awful.

DisplayID, the replacement for EDID, is going to become much more prevalent, and we discussed how we’re going to roll out support in the kernel and in libdisplay-info.

We once again managed to put enough wayland developers in a room for a bigger protocol change to get merged. This time it was multi device dmabuf feedback which made Victoria Brekenfeld happy.

There was a lot more happening — check out Xaver’s and Louis Chauvet’s blog posts.

Even though I wasn’t as prepared as the previous times, it was very productive and there was more actual hacking this year. I also enjoyed meeting everyone again a lot, hanging out in the water while watching the 1% take off in their private jets, struggling to find an adequate Döner, and eating lots of pizza.

Until next time!

• Up too early, mail chew, plugged at stats generation. Encouraging scripting call with Stephan and others.
• Sync with Gokay, Tracie, Anna & Laser, then Tobias & Thorsten, Alex & Victor, Anna & Timur then snatched lunch.
• Published the next strip: An interview with Brigit - who wants everyone to be happy
  
• COOL TC meeting, some hacking, chat with Dave, admin.

GNOME’s Code of Conduct is our community’s shared standard of behavior for participants in GNOME. This is the Code of Conduct Committee’s periodic summary report of its activities from October 2025 to June 2026.

The current members of the CoC Committee are:

• Anisa Kuci
• Carlos Garnacho
• Christopher Davis
• Federico Mena Quintero
• Michael Downey
• Rosanna Yuen

All the members of the CoC Committee have completed Code of Conduct Incident Response training provided by Otter Tech, and are professionally trained to handle incident reports in GNOME community events.

The committee has an email address that can be used to send reports: conduct@gnome.org as well as a website for report submission .

Reports

Since October 2025, the committee has received reports on a total of 17 possible incidents. Several of these were not actionable; all the incidents listed here were resolved during the reporting period. There is currently a total of 7 incidents in process.

• We were made aware of concerns regarding online comments made on social media by a GNOME Foundation member. Upon review, we found these comments to fall outside the scope of the Code of Conduct in this instance.
• Report about messages sent to a Telegram channel. Contacted the reported person about the inappropriate nature of the messages.
• Report about unfriendliness to newcomers in a localisation team. Asked the team lead to write down documentation on their procedures.
• Question about clarification on the CoC’s text; replied suitably since the question was not actually about the CoC’s contents.
• Tech support request; redirected to discourse.gnome.org.
• Malicious question; closed without reply.
• Report about homophobia; removed privileges for the reported person.
• Report about a Mastodon post which was subsequently removed. Reminded the reported person that Mastodon posts in the context of GNOME are also under the scope of the Code of Conduct.
• Report about two Mastodon posts which were subsequently removed. Reminded the reported people that Mastodon posts in the context of GNOME are also under the scope of the Code of Conduct.
• Report about a TWIG submission, not actionable as there is no violation of the CoC.
• Report unrelated to GNOME; notified the reporter and closed as non-actionable.
• Report about an interaction in gitlab.gnome.org. Reminded the reported person about how to politely deal with disagreement.
• Tech support request; already solved.
• Report about suspicious activity in Matrix; not actionable other than to keep an eye out for the reported person.
• Report about a person exhibiting bad behavior outside of the scope of the CoC. We will keep an eye on it.

Meetings of the CoC committee

The CoC committee has two meetings each month for general updates, and weekly ad-hoc meetings when they receive reports. There are also in-person meetings during GNOME events.

Ways to contact the CoC committee

• https://conduct.gnome.org – contains the GNOME Code of Conduct and a reporting form.
• conduct@gnome.org – incident reports, questions, etc.

The website repository, and the Code of Conduct itself and the committee’s procedures, are kept at https://gitlab.gnome.org/Teams/Conduct/gnome-code-of-conduct

The Code of Conduct Committee is happy to receive questions about the CoC itself and its procedures, and we will gladly assist you. Please use the communications channels listed above.

July is Disability Pride Month . I want to use the occasion to speak about my perspective on accessibility in GNOME and what I think we should do.

For disabled people, computers are often even more important than for abled (non-disabled) people. Many areas of everyday life are currently only accessible via a computer for many disabled people. Still, accessibility is often an afterthought in software and hardware development.

GNOME is fortunate enough to have many disabled contributors in its community. We have contributors who are visually impaired, deaf, autistic, ADHD, or who live with migraines and other chronic conditions. While we have people that care about accessibility and work on improving it, the general state is far from ideal.

The reality of tech communities is that they are often ableist and elitist. Probably more so than the average population. If a user or contributor struggles with a tool, blame is shifted to a “skill issue,” if an interface is simplified to make it accessible to more people, it’s “ dumbed down ”. Assistive technologies are often developed by abled people, without involving and paying disabled people. This also leads to an attitude where contributors expect gratefulness from disabled people for providing them with the most basic needs. All these issues are also not absent from the GNOME community.

What We Already Do

The goal of this section isn’t to boast about GNOME’s accessibility efforts. I believe that accessibility is a fundamental right, and nothing any disabled person is obligated to praise contributors for. Instead, the goal is to capture where we stand, and give other projects ideas they can adopt. Equally, I would be very happy to learn how other FLOSS projects try to work towards better accessibility.

Our review criteria for Core and Circle apps require checking if keyboard navigation, screen reader support, large text, and high contrast mode work. We also require sufficient contrast in apps, which we usually use the Contrast app to check against the WCAG requirements. We have shown that we are able to enforce these requirements by delaying the inclusion or replacement of apps until accessibility issues were actually fixed. That’s also an improvement GNOME has seen over the last years, since originally, no quality criteria for apps existed.

Many of the accessibility aspects are automatically covered by using our toolkits GTK and libadwaita correctly. I witnessed that accessibility is often considered during initial design and implementation. However, we don’t have any guidelines or requirements in GNOME for the development of these libraries.

The GNOME Foundation funded work on screen reader support in GTK 4 in 2020 and 2021. In 2023 and 2024, accessibility was also one of the larger areas the GNOME STF project worked on. That means both the GNOME Foundation, and the STF organizers were willing to allocate money for accessibility, which is a good sign.

However, accessibility is so much more than screen reader support. I think that GNOME’s general design philosophy is very important to being more accessible to a broader audience. This includes the focus on simplicity with good defaults, trying to avoid the possibility of misconfiguring the system, and the attempt to distract less. Translations, while often overlooked as an accessibility aspect, are another huge factor that makes our software accessible to so many more people. This shows that accessibility is hardly a separate set of features. Instead, it has to be considered as part of every area in a project.

Among the more “traditional” accessibility tools within GNOME are the screen reader, high contrast, reduced motion, always show scrollbars, sound over-amplification, input adjustments, and magnification. But equally important are the “Dark Mode” and “Do Not Disturb” mode, which are not directly labeled as accessibility.

How We Can Improve

Disability Pride is about being proud of who you are . But, like Queer Pride, it is also about fundamentally changing the society in which we live. Hence, for this year’s Disability Pride, I am also thinking of what we can change within GNOME.

Create an Accessibility Team

Except for a dedicated accessibility chat room, there is currently very little coordination for accessibility within GNOME. My goal for this month is to establish a formal Accessibility Team. My initial ideas for the team are to prioritize voices of those with lived experience, instead of having others make decisions for us. Nothing about us without us. In more practical terms, the team should help to maintain and develop guidelines and review criteria that are especially relevant for accessibility. The team should also review larger changes in the GNOME project that affect accessibility. Ideally, we could provide and user testing on accessibility features directly from the people who rely on them.

In addition to guarding the accessibility aspects of the software we produce, the team should also advocate for accessibility in our events, workflows, and tooling.

If you are interested in contributing, please reach out via #a11y or in our issue #1 . Let us know where and how you want to contribute.

Use This Month Yourself

If you are disabled, and you want to share your experience in FLOSS communities or have accessibility issues in GNOME or other FLOSS software, report the issues and/or post about them on social media under #AccessibilityInFreeSoftware .

If you are a contributor, see if you can tackle one of the roughly 450 open issues that are labeled with “Accessibility” this month. Try to broaden your horizons by reading articles from disabled people you know less about, or follow them on a social media platform. Embrace accessibility as a fundamental human right, not something disabled people have to show gratefulness for. Try to reflect on your language. Don’t use sanist language like “sane defaults,” using “good defaults” does the job. Ask yourself if you want to keep words like “idiot” in your vocabulary, knowing that “idiocy” was the first category the Nazis used to systematically kill people .

But also, don’t be scared of disabled people. We want to and deserve to be part of the community like everyone else.

Happy Disability Pride Month! Let’s build a desktop that is accessible to as many people as possible.

This blog post represents my personal opinions and not those of any organization I work for.

Week 25

This week's icon is for Val Packett 's project:
Demostage : "Perform live demos from a virtual desktop"

Check out all weekly app icons created so far over here and follow my icon creation adventures as they happen (including sketches) on the Fediverse .

Need icons?

I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source . Funded by community sponsors (every little helps!).

I couldn't remember something for weeks. It popped into my head during a run — a relief, even though the memory itself was not pleasant. This episode of my flaky mind reminded me of this movie.

I won't give you even a hint of what the movie is about. The strength of it is not the premise, but the mood, the superb acting and Christian Bale's physical dedication to the role impressed me, alongside a cast of wonderfully weird characters and ominous presence of giant spinning machines. If you somehow missed the movie, give it a go. It's one of those that keep coming back to you.

• Up early, packed variously, bid 'bye to M&D, and the American Meeks.
• Into Cambridge for H's baptism at Christ Church; with B&C&C, Mary Rogers and several of H's friends. A lovely service & dunking - out to Browns for lunch together.
• Bid 'bye to N., dropped M & J & Sade to the station to help move M. into her new London home.
• Dropped Mary home, slugged a bit, prepped music for and ran the evening service - Charlee spoke well. Relaxed.

Week 24

This week's icon is for Jiří Eischmann 's project:
Meshy : "Meshcore mesh network client"

Check out all weekly app icons created so far over here and follow my icon creation adventures as they happen (including sketches) on the Fediverse .

Need icons?

I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source . Funded by community sponsors (every little helps!).

Update on what happened across the GNOME project in the week from June 26 to July 3.

Third Party Projects

Haydn Trowell says

The latest version of Typesetter updates the built-in Typst compiler to version 0.15, which brings a long-awaited feature: variable font support – no more warnings and faulty font rendering when using your system’s default fonts. This release also adds a popularly requested feature to the editor: manual font size adjustment – use the standard keyboard shortcuts to make the text larger and smaller.

Get it on Flathub: https://flathub.org/apps/net.trowell.typesetter

albfan reports

Finally is here: gitg 50, more stable and customizable

Full of new actions to interact with your git repos, even customizable ones

Once downstream packaging is available, give it a try and send feedback

Shell Extensions

Fabiano Junior says

Hello everyone! I’ve just released new updates for ChromaLeon , my extension that extracts and applies colors from your wallpaper to your GNOME Shell and LibAdwaita theme.

The focus of these updates was refinement: the color extraction system is now smarter, ensuring better compliance with WCAG accessibility guidelines regarding contrast. Additionally, I’ve improved the icon generation system (folders and apps) to make it much faster and more efficient, now generating icons almost instantly.

You can check out the project on GitHub and GNOME Extensions .

storageb reports

Create custom time-of-day schedules for the Night Light!

Night Light Scheduler lets you create a custom schedule for GNOME’s built-in Night Light allowing you to automatically adjust the color temperature throughout the day according to your schedule.

Features:

• Create a schedule to automatically adjust Night Light color temperature throughout the day
• Smoothly transition between temperatures with an adjustable transition time
• Import and export schedule configuration as an editable .ini file
• Uses GNOME’s built-in Night Light functionality
• Easy to use visual interface

More information is available on the project’s GitHub page .

Miscellaneous

Cleo Menezes Jr. | World Cup mode 🇧🇷🇧🇷 says

Mosaic WM is maturing and being refined, polishing the rough edges, finding bugs, hearing from you.

To do that, I’ve created a Matrix room and I’d like you to be there. You don’t need to be an expert, just someone who wants to help make it better.

In?

Damned Lies ↗

The internal application to manage localization of GNOME & friends modules

Guillaume Bernard announces

This week, we released for Damned Lies a new feature for team coordinators. When updating your team details, you can now create a presentation that will be sent to new team members as a notification. Use it to present the team, the workflow, link your docs, identify a module for newcomers…

Internships

AnonymouX47 announces

Five weeks into GSoC 2026, I’ve made solid progress on GPU reset recovery in Mutter!

When a GPU reset occurs, Mutter currently has no way to recover; the desktop either freezes or crashes. My project implements a recovery path: detecting the reset, waiting for it to complete, recreating the context, and propagating that change through the compositor to recreate resources so rendering can resume.

The display now comes back after a reset, and the session remains usable, though there’s still work ahead: notably, automatic framebuffer recreation and fixing the desktop background, which currently renders with garbled textures after recovery.

Read the full details, including a demo: https://blogs.gnome.org/anonymoux47/2026/07/02/gpu-reset-recovery-in-mutter-a-progress-update

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!