Eurosky’s mission is to establish independent social media infrastructure operating in Europe, where Igalia is headquartered, and governed by European law. Our shared goal is to work together to develop core components and tools for the AT Protocol and its overall ecosystem. The fruits of this collaboration will be placed under an MIT License, ensuring that our work remains freely available for developers and organizations building on the open social web.

We at Igalia are excited to be a part of this effort and its vision of a more open, pluralistic, and resilient social web in which users, developers, and communities have genuine choice over the platforms and services they use.

About Eurosky

Eurosky is a public interest, non-profit, technology organization working towards a thriving open social web for Europe. We build and maintain shared infrastructure on open protocols that enable European entrepreneurs, businesses, and organizations to launch social applications faster and more affordably. We build apps and solutions for people that prioritize interoperability, user control, and democratic values. All our technology solutions are hosted in Europe and governed by European law. Eurosky is an initiative of the Modal Foundation, a non-profit organization headquartered in the Netherlands.

About Igalia

Igalia is a leading open source consultancy with 25 years of experience, headquartered in Europe but operating with a global reach. As an organization deeply committed to the open source philosophy, Igalia has built its reputation on technical excellence and collaborative development, working with clients and partners across the world. Igalia is best known for the development of open web standards and browser engines, including Chromium, WebKit, and Gecko, where it stands out as the largest contributor to all major web engines second only to their primary developers. Beyond the browser, Igalia’s engineers are active contributors to a broad spectrum of technologies, including compilers, multimedia frameworks, graphics systems, and the Linux kernel, among others. Igalia is committed not just to any single technology, but to the health and advancement of the open source ecosystem as a whole.

Several current and former Igalians contributed to Temporal. Ms2ger brought years of careful spec writing and vital review work; Philip Chimento and Ujjwal Sharma co-championed the proposal. Aditi Singh, Ben Allen, Cam Tenny, Dan Ehrenberg, Eric Meyer, Guillaume Emont, Ioanna Dimitriou, Jesse Alama, Romulo Cintra, Sarah Groff Hennigh-Palermo, and Tim Chevalier all contributed throughout the project’s life. Bloomberg, whose collaboration with us first got us working on it, funded the work and contributed engineering directly.

Besides its default ISO 8601 calendar, Temporal also supports a number of regional calendars — Gregorian, Japanese, Hebrew, Persian, Chinese, Islamic, and others. To ensure these work consistently across implementations, a companion ECMA-402 proposal was also needed. The Intl.era and Intl.monthCode proposal specifies the details Temporal deliberately leaves open: the valid era codes, eraYear semantics, and monthCode values for each of those calendars. We worked on this as part of our long-running collaboration with Google’s i18n team, with Ben Allen, Philip Chimento, and Ujjwal Sharma as the main contributors from our side.

Igalia also ended up working on RFC 9557, the Internet Extended Date/Time Format (IXDTF). Temporal needs a standard way to serialize timestamps with timezone and calendar information, but the conventions in wide use — like appending IANA timezone names to timestamps — had never been on a formal standards track. RFC 9557 fixes that, and also defines the new syntax for calendar annotations ([u-ca=hebrew] and similar) that Temporal requires for round-tripping dates across calendar systems.

Temporal adds immutable date/time types, explicit timezone handling, support for a variety of international calendars, and nanosecond precision. It ships with around 4,500 test262 tests — Date, for comparison, has 594. Firefox v139, Chrome v144, Edge v144, and TypeScript 6.0 beta already include it. If none of these are available, you may also use Temporal from a polyfill, including the reference polyfill developed by the champions initially.

Back when Temporal reached Stage 3 in 2021, we recorded an Igalia Chat on the proposal with Brian Kardell, Philip Chimento, Maggie Johnson-Pint (Moment.js), and Philipp Dunkel (Bloomberg). A lot has changed since then — and we just sat down together with Philip, Nicolò Ribaudo, and Bloomberg’s Jason Williams to talk about the Stage 4 advancement!

Congratulations to everyone who kept this moving. It took nine years and a lot of people, and hopefully will improve the lives of JavaScript developers. We’re looking forward to seeing more robust date handling deployed on the Web and beyond!

Today we are announcing the launch of Moonforge, a new Linux distribution based on the Yocto and OpenEmbedded projects and designed to provide a fully open-source, production-ready foundation for building embedded and device operating systems.

Moonforge focuses on extensibility, flexibility, and long-term maintainability, enabling developers and system integrators to create custom operating system images while relying on well-established industry tooling and best practices.

The project is available as open-source on GitHub and welcomes community contributions.

Building Production-Ready Linux Systems with Yocto

Moonforge is an operating system framework for Linux devices that simplifies the process of building and maintaining custom operating systems.

It provides a curated collection of Yocto layers and configuration files that help developers generate immutable, maintainable, and easily updatable operating system images.

The goal is to offer the best possible developer experience for teams building embedded Linux products. Moonforge handles the complex aspects of operating system creation, such as system integration, security, updates, and infrastructure, so developers can focus on building and deploying their applications or devices.

Using Moonforge, developers can:

• Build their own operating system by combining modular Yocto layers
• Rely on widely adopted industry standards
• Extend the system with additional features, hardware support, and integrations
• Maintain a clear separation between upstream and downstream components

Design Goals

Moonforge is designed around three core principles: balance, separation, and best practices.

Balance Between Turn-Key Solutions and Flexibility

Creating a Linux distribution typically requires significant integration work: selecting components, configuring build systems, and aligning the system architecture. Moonforge reduces this duplicated effort by providing sensible defaults and core architectural decisions, while still allowing teams to customize and extend the system for their own products.

The project combines Yocto layers together with extensive use of kas, a tool for managing configuration in a declarative way using YAML. By assembling layers and configuration fragments, developers can easily create different operating system variants and product configurations tailored to their needs. This modular approach encourages reuse of common components while allowing teams to maintaine full control over the final system.

Clear Separation of Components

Moonforge is structured to maintain a clear separation between upstream and downstream components, making it easier for organizations to build derivative products. Existing Moonforge layers cover common use cases, while the Yocto layer architecture allows vendors and developers to add their own functionality when needed.

Kas configuration fragments are used to handle tasks such as:

• Including required external repositories
• Activating the necessary layers within those repositories
• Managing dependencies between Moonforge components
• Applying downstream patches and configuration defaults

This structure ensures predictable builds and simplifies release management for derivative systems.

Best Practices for Modern Linux Systems

Moonforge adopts established best practices for building Linux-based operating systems. It relies on proven tools and technologies like BitBake for image creation and kas for build configuration and reproducibility.

Modern development workflows are supported out-of-the-box by providing CI/CD pipelines to automatically build and publish:

• OS images
• Over-The-Air update bundles
• Security reports
• Software Bill of Materials (SBOM) metadata

Moonforge is also capable of integrating with different deployment and update mechanisms, like systemd, RAUC, or Mender.

The project is designed to support build environments across public cloud, private infrastructure, and local development systems, ensuring teams can adopt it within their existing workflows.

An Open Project for the Embedded Linux Community

Moonforge is developed as an open-source project and aims to support a wide range of Linux devices and embedded products. Additional layers, features, and hardware platforms will continue to be added as the project evolves. Contributions from the community are encouraged.

Developers interested in building their own Linux operating systems or extending Moonforge can explore the project and contribute on GitHub.

• CSUN Accessibility Technology Conference from March 9th to 13th in Anaheim, CA, USA.
• 113th TC39 meeting from March 10th to 12th in New York, USA.
• Embedded World Conference from March 10th to 12th in Nuremberg, Germany. We’ll be in Hall 4, Booth Number 4-443, as well as presenting two talks:
  • “Modern Yocto Linux Best Practices: Evolving Beyond the Basics” by Marga Manterola
  • “Web Engines for Embedded Devices: An Introduction to WPE WebKit” by Mario Sanchez
• Wasm I/O, from March 19th to 20th in Barcelona, Spain, where Saúl Cabrera will be presenting “Beyond Performance: 5 Years of Improving JavaScript on WebAssembly”, an exploration of the multidimensional problem of optimizing JavaScript on WebAssembly.

We always enjoy talking with people, so if you find yourself at one of the above events, please take a moment to say hi! And if you have any questions regarding any of our talks, are interested in having an Igalian bring a talk to an upcoming event, or you’d just like to learn more about Igalia, please feel free to reach out.

CE participants receive financial compensation of €7,000 for 450 hours of work time over a period of either 3 or 6 months, on a schedule that works best for you. Each CE participant is mentored by one of Igalia’s outstanding open source contributors, and acquire knowledge and skills that will benefit them well beyond the program. The Coding Experience is remote-friendly, in keeping with Igalia’s fully-remote structure.

Applicants to the program can be students enrolled in an official education program, such as a college degree program, or can be students in alternative learning itineraries (e.g., self-learning). The CE program is also open to people who are in a later stage of their professional career, do not have experience working in tech fields, and are willing to refocus.

Igalia welcomes all applicants regardless of their age, disability, gender, race, marital status, religion, sexual orientation, or any other marginalized identity. Due to our strong commitment to diversity and inclusion, we would like to expressly invite individuals from underrepresented communities in our industry to apply.

The application period is open through April 3rd, 2026, with applicants being informed of their acceptance status by mid-May. If you’re interested in learning more about the Coding Experience program or you are ready to apply, please visit the Igalia Coding Experience page.

The Interop 2025 results were outstanding, with the overall interoperability score of its focus areas climbing from 28 to 95 in the course of the year; this has further moved up to a score of 97 in the month since the end of 2025. We’re excited about the prospect of similar improvements in this year’s focus areas!

HTML

At the markup layer, there wasn’t one proposal that stood out, but rather a collection of a few proposals related to dialogs and popovers — not just the <dialog> element and the popover attribute, but also the :open pseudo-class in CSS. There were some things still missing in implementations, and others that weren’t handled consistently. The Interop team combined the proposals into a single HTML focus area.

CSS

As is often the case, the presentation layer got a lot of attention from proposers, which led to eleven focus areas rooted in CSS. These are:

• Advanced attr()
• Container style queries
• contrast-color() function
• Custom highlights
• Media pseudo-classes
• Scroll-driven animations
• Scroll snap
• shape() basic shape function
• Anchor positioning (carryover from 2025)
• View transitions (carryover from 2025)
• CSS zoom (carryover from 2025)

JavaScript

At the scripting layer, the Interop team chose these seven focus areas:

• Fetch uploads and ranges (combined three separate proposals into one focus area)
• IndexedDB
• JSPI for Wasm
• Navigation API
• Scoped custom element registries
• WebRTC
• WebTransport

Web compat(ibility)

While all of Interop can be considered a web compat effort, there are always a few areas where the amount of work to achieve full alignment is small, but worth taking on as official focus areas. Sometimes, this can mean getting clarification from relevant W3C working groups, or doing origin trials to make sure the change is sufficiently low-impact. This year, work will focus on web compatibility issues with:

• ESM module loading
• The timing of scroll events relative to animation events
• Unprefixing the -webkit-user-select property

Investigation areas

Each year, the Interop team chooses a small number of areas to investigate how to get the proposals into future Interop years. This is usually done for proposals that lack the tests, or the testing infrastructure, to qualify as official focus areas. The 2026 investigations will be:

• Accessibility testing
• JPEG XL tests
• Mobile testing
• WebVTT

If you’d like to read more about Interop 2026, see the articles published today by Apple, Google, Microsoft, and Mozilla.

Igalia is proud to once again be part of the Interop process, and to champion a few proposals that are particularly close to our interests. We look forward to seeing all the progress this year will bring.

Following the TAG’s recent election results, the W3C Team has chosen and the Advisory Board and Technical Architecture Group have ratified our very own Brian Kardell for the 2026-28 term as one of the two appointments they will make for this term.

Brian, who started hacking on the web as early as 1996, has well over a decade of experience working in web standards and core technologies, contributing to its continued development, whether it be through championing for important yet underappreciated features or through advocating for the platform at large.

All in all, we believe Brian will be an excellent addition to the group and a champion for a free and extensible web. Congratulations to Brian as well as the W3C TAG on this appointment!

Linux 6.19 is the first release of 2026, shipping several contributions from Igalia among its more than 14 thousand commits — keeping up the consistent work from last year. Have a look at our 2025 retrospective! For an overview of this kernel release and features, check the KernelNewbies page.

Once again, our team delivered improvements, features, and bug fixes across different areas of the kernel — ranging from debugging and core infrastructure to filesystems, energy model, graphics drivers and APIs, and more; helping our clients in many domains and benefiting the wider Linux community.

Speaking of the Linux community, as previously announced, some of our contributions and related work were presented at the Linux Plumbers Conference 2025, discussing their context, challenges, and more details. In the sections below, we provide links to individual talk videos on Youtube.

The next section describes Igalia’s contributions to Linux 6.19.

Igalia Changelog

page_owner improvements

In the memory management subsystem, page_owner is a debug feature for memory allocations. It stores the stack trace of the memory allocation of every page, and can report which stack trace allocated a page and how many pages are allocated by a stack trace, among other things.

We have improved page_owner’s userspace interface in debugfs, providing options to reduce the amount of data produced by the kernel and consumed by userspace, which allows for more efficient continuous data collection.

This is helpful for use cases such as profiling and monitoring the memory allocation/usage in the system, which page_owner can do with page granularity plus stack trace insight.

More details are available in the presentation at the Linux Plumbers Conference 2025.

Futex improvements

Continuing the effort made in 6.18, we once again made improvements on the Futex selftests. This time we added the kernel seftests for the set/get_robust_list() syscalls. Despite this syscall being around for about 20 years, it never had a test in the kernel tree… until now! The new selftest provides a good coverage and should track regressions when modifying the robust_list internals, and also can be used as a documentation about how to use this uAPI.

These improvements on the futex system call are part of a big effort on adding a new interface for the set_robust_list(). You can learn more about this in the Linux Plumbers Conference 2025 presentation.

FUSE periodic dentries invalidation

Filesystem in Userspace (FUSE) caching is usually handled at the kernel level by the FUSE subsystem. Obviously, the data cached by the kernel needs to be maintained as it can either: 1) be explicitly marked as invalid by the FUSE user-space server, or 2) become too old, by means of having a timeout associated with it.

We have just added a new mechanism to periodically invalidate the FUSE cached data. This mechanism includes the infrastructure to keep all the dentries sorted by expiry time in a tree structure so that expired data can be efficiently invalidated. To enable this new feature, an extra FUSE module parameter was added. It can to be set to a value, in seconds, which will be the period for a workqueue that will take care of the invalidation of expired dentries.

Energy Model (EM) Netlink Interface for sched_ext and Beyond

Schedulers built on sched_ext, such as LAVD, must understand performance–power trade-offs to make informed, energy-aware scheduling decisions. The Linux kernel’s Energy Model (EM) provides this information, capturing details such as CPU cluster topology and the power cost associated with operating at specific CPU frequencies.

However, there is currently no suitable interface for accessing the Energy Model from either BPF programs or userspace. To address this limitation, we introduce a netlink interface that exposes Energy Model information for a given SoC. This interface allows userspace applications to query EM data and receive notifications when the model changes—for example, due to thermal condition updates.

With this patchset, sched_ext-based schedulers and related tooling can incorporate up-to-date energy characteristics into their decision-making process. More details on Energy Model–Aware Scheduling (EMAS) in LAVD are available in this presentation at the Linux Plumbers Conference 2025.

AMD GPU kernel driver improvements

We have added a capability to the common DRM TTM layer, where drivers are now able to hint above what allocation size it is not worth trying too hard to allocate contiguous memory. This allows for better worst case large buffer allocation latency under memory pressure, where the TTM layer will now not try to do direct memory reclaim above the configured threshold.

As kernel developers, we often need to load and unload modules multiple times for various reasons, one of the primary ones being to save time by avoiding system reboots. However, we encountered issues with the load/unload feature across multiple devices, including the Steam Deck. While we addressed problems for other devices, the APU, particularly in the Steam Deck, presented a unique challenge: the device must be reset during the unload/load sequence to ensure the firmware is in a proper state.

In this release, we implemented a fix that triggers a GPU reset on APUs at the time of unloading, effectively resolving the reload issue. Additionally, we observed that on Renoir devices, the reset was mistakenly applied during the loading phase, leading to increased latency during boot. Since the fix is applicable to all APUs, we can now remove the workaround for Renoir devices, which should improve boot speed on those systems.

New KMS Plane Color Management API

We actively participated in design, reviews and testing of the new KMS Plane Color Management API. With this new generic KMS API, kernel display drivers can expose their color capabilities before blending, allowing compositors to offload more color transformations to the display hardware (freeing the GPU for Graphics workload) for advanced color management and better HDR support. Moreover, most of the AMD support for this new API was based on our previous implementation of AMD driver-specific color management properties, a work we started with gamescope and got merged to the mainline kernel in 2023.

Other

We also contributed bug fixes to the amdgpu driver and a nfc driver, and an improvement in the sound subsystem, along with reviews, acks, and a maintainer sign-off.

Authored (42)

André Almeida

• selftests/futex: Remove unused test_futex_mpol()
• selftests/futex: Create test for robust list

Changwoo Min

• PM: EM: Assign a unique ID when creating a performance domain
• PM: EM: Expose the ID of a performance domain via debugfs
• PM: EM: Add em.yaml and autogen files
• PM: EM: Add a skeleton code for netlink notification
• PM: EM: Add an iterator and accessor for the performance domain
• PM: EM: Implement em_nl_get_pds_doit()
• PM: EM: Implement em_nl_get_pd_table_doit()
• PM: EM: Implement em_notify_pd_deleted()
• PM: EM: Implement em_notify_pd_created/updated()
• PM: EM: Notify an event when the performance domain changes
• PM: EM: Fix yamllint warnings in the EM YNL spec
• PM: EM: Rename em.yaml to dev-energymodel.yaml
• PM: EM: Change cpus’ type from string to u64 array in the EM YNL spec
• PM: EM: Add dump to get-perf-domains in the EM YNL spec

Luis Henriques

• dcache: export shrink_dentry_list() and add new helper d_dispose_if_unused()
• fuse: new work queue to periodically invalidate expired dentries
• fuse: new work queue to invalidate dentries from old epochs
• fuse: refactor fuse_conn_put() to remove negative logic.

Mauricio Faria de Oliveira

• mm/page_owner: introduce struct stack_print_ctx
• mm/page_owner: add struct stack_print_ctx.flags
• mm/page_owner: add debugfs file ‘show_handles’
• mm/page_owner: add debugfs file ‘show_stacks_handles’
• mm/page_owner: update Documentation with ‘show_handles’ and ‘show_stacks_handles’

Melissa Wen

• drm/amd/display: fix wrong color value mapping on MCM shaper LUT
• drm/amd/display: extend delta clamping logic to CM3 LUT helper
• drm/amd/display: remove assert around dpp_base replacement

Rodrigo Siqueira

• drm/amdgpu: Fix GFX hang on SteamDeck when amdgpu is reloaded
• Revert “drm/amd: fix gfx hang on renoir in IGT reload test”

Thadeu Lima de Souza Cascardo

• Revert “nfc/nci: Add the inconsistency check between the input data length and count”

Tvrtko Ursulin

• drm/amdgpu: Use memset32 for IB padding
• drm/ttm: Add getter for some pool properties
• drm/ttm: Replace multiple booleans with flags in pool init
• drm/ttm: Replace multiple booleans with flags in device init
• drm/ttm: Allow drivers to specify maximum beneficial TTM pool size
• drm/amdgpu: Configure max beneficial TTM pool allocation order
• drm/ttm: Add an allocation flag to propagate -ENOSPC on OOM
• drm/gem: Use vmemdup_array_user in drm_gem_objects_lookup
• drm: Do not allow userspace to trigger kernel warnings in drm_gem_change_handle_ioctl()
• drm/xe/xelp: Fix Wa_18022495364

Umang Jain

• ALSA: pcm: Harden the spk_alloc assumption check

Reviewed (36)

Changwoo Min

• PM: EM: Fix memory leak in em_create_pd() error path

André Almeida

• drm/gem: Use vmemdup_array_user in drm_gem_objects_lookup

Changwoo Min

• sched_ext: Make scx_bpf_dsq_insert*() return bool
• PM: EM: Add to em_pd_list only when no failure

Luis Henriques

• fuse: Uninitialized variable in fuse_epoch_work()

Melissa Wen

• drm: Add helper for conversion from signed-magnitude
• drm/doc/rfc: Describe why prescriptive color pipeline is needed
• drm/colorop: Introduce new drm_colorop mode object
• drm/colorop: Add TYPE property
• drm/colorop: Add 1D Curve subtype
• drm/colorop: Add BYPASS property
• drm/colorop: Add NEXT property
• drm/colorop: Add atomic state print for drm_colorop
• drm/plane: Add COLOR PIPELINE property
• drm/colorop: Introduce DRM_CLIENT_CAP_PLANE_COLOR_PIPELINE
• Documentation/gpu: document drm_colorop
• drm/colorop: Add destroy functions for color pipeline
• drm/colorop: Add 3x4 CTM type
• drm/colorop: pass plane_color_pipeline client cap to atomic check
• drm/colorop: define a new macro for_each_new_colorop_in_state
• drm/amd/display: Ignore deprecated props when plane_color_pipeline set
• drm/amd/display: Skip color pipeline initialization for cursor plane
• drm/amd/display: add 3x4 matrix colorop
• drm/colorop: Add multiplier type
• drm/amd/display: add multiplier colorop
• drm/amd/display: Swap matrix and multiplier
• drm/colorop: Define LUT_1D interpolation
• drm/colorop: allow non-bypass colorops
• drm/colorop: Add 3D LUT support to color pipeline
• drm/amd/display: Add AMD color pipeline doc

Tvrtko Ursulin

• drm/sched/tests: Remove relict of done_list
• dma-buf: rework stub fence initialisation v2
• drm/amdgpu: jump to the correct label on failure
• dma-buf: cleanup dma_fence_describe v3
• drm/gem: Correct error condition in drm_gem_objects_lookup

Umang Jain

• staging: vchiq_arm: delete unnecessary check

Acked (3)

Changwoo Min

• tools/sched_ext: Strip compatibility macros for cgroup and dispatch APIs

Christian Gmeiner

• drm/etnaviv: add HWDB entry for GC8000 Nano Ultra VIP r6205

Tvrtko Ursulin

• drm/ttm: Fix @alloc_flags description

Maintainer SoB (1)

Christian Gmeiner

• drm/etnaviv: add HWDB entry for GC8000 Nano Ultra VIP r6205

Our Response

Igalia is an international open source consultancy with over 25 years of experience, based in Europe but with partners all over the world. We are significant contributors to key open source technologies like web engines, compilers, graphics drivers and multimedia systems, among others. We welcome these new steps to increase Europe’s technological sovereignty based on open source solutions, and we are willing to contribute with our resources and knowledge to advance that goal. We would also like to make some high level comments about the existing situation:

1. Properly directed funding can have have a major impact on open source technologies and software sovereignty.
   • While we strongly welcome and encourage EU funding, the complexity of gaining access to it for funding open source projects has historically been very prohibitive for us. We believe that it is crucial to not only add funding, but to radically streamline these processes. The EU Sovereign Tech Fund, if scaled up, could provide a good blueprint.
   • Funding should not focus just on pure R&D, but also long-term maintenance and the production of industry-ready solutions. Up to 100% of direct costs should be available for projects producing open source output.
   • More than anything, reliable sources of financing should be created for European companies that want to invest in open source technologies for the European market. Public procurement or stable public-private partnerships, among others, could be key tools to tackling this problem.

2. However, we must also avoid basing this on a naive understanding of software sovereignty. We should not think we have to reimplement everything from the ground up, or insist that all decisions be made only by Europeans. We must be able to keep working with friends and allies all over the world, when possible. We believe that we must help to advance viable governance solutions for international open source ecosystems where Europeans are major players and feasibly able to fork if necessary.

3. We believe open source is strategically important for Europe, but that open source alone is not sufficent to sovereignty.
   • In the short-term, there are critical gaps to fill. In some cases, our basic digital infrastructure in Europe is 100% controlled from elsewhere and dependent on foreign companies. There cannot be “kill switches” for mission-critical software deployed in our institutions and companies. This has to be solved ASAP. Some compromises that iteratively improve the status quo might be necessary.
   • There are long-term problems which will not be solved immediately, but where Europe could be a leading actor for change, and where we should focus on getting the fundamentals right. Protocol-based solutions where the playing field is defined in a fair manner for everyone and where applications can be swapped in and out as long as they respect that common protocol are a very strong guarantee of sovereignty and freedom. We believe we should focus our energies, in terms of investment and development, on the “common protocol and diversity of applications” model: that of the internet, the web, and new developments like open social (atproto, activitypub and others). We should expand that model to as many places as possible.

These are just some brief thoughts about some what we understand to be key issues, both urgent and long-term. Again, we are happy to be part of this process and we are happy to continue this conversation with the Commission and other members of the community.

This retrospective focuses on the two areas where our impact was most significant: upstream Linux kernel development and the sched_ext ecosystem.

Linux Kernel Contributions 2025

In 2025, Igalia continued its long-standing commitment to upstream Linux development, contributing extensively to the Linux Kernel across releases 6.13 through 6.18. Rather than isolated changes, this year stands out for sustained work with impact across multiple kernel subsystems, focused on performance, robustness, and enabling new capabilities—particularly in graphics, scheduling, memory management, and filesystems.

Below is a thematic retrospective of the most significant achievements of 2025.

sched_ext: Making BPF Schedulers Faster and Safer

In 2025, sched_ext became one of the most impactful kernel areas, delivering measurable performance gains while significantly improving correctness and robustness.

By enabling fully custom, BPF-based schedulers on top of the Linux scheduler core, sched_ext moved beyond the experimental stage. Igalia’s contributions focused on removing key performance bottlenecks, hardening critical execution paths, and improving observability — laying the foundation for the sched_ext ecosystem discussed further below.

• Hardening the core (6.13) Fixed lock misuse and missing RCU protections that could otherwise lead to kernel crashes, ensuring that sched_ext could be safely used and extended without risking system stability.
• Performance boost for BPF schedulers (6.14) One of the most impactful sched_ext contributions in 2025 addressed a clear performance bottleneck. Many BPF schedulers (such as scx_lavd) relied heavily on bpf_ktime_get_ns(), which on some architectures triggers expensive hardware TSC reads and degrades IPC. Igalia introduced scx_bpf_now(), reusing the scheduler runqueue clock when available and eliminating much of this overhead. The results were decisive:
  • 50–80% reduction in hardware TSC reads
  • ~76% reduction measured on real sched_ext workloads
• Improved introspection (6.15) Added internal event counters, giving scheduler developers great visibility into subtle runtime behavior. The events can be monitored through a BPF program, sysfs, and a tracepoint.

Filesystems: Case-Insensitivity and Container-Friendly Linux

Expanding case-insensitive filesystem support was a key user-facing theme in 2025, particularly for gaming and containerized workloads.

• Tmpfs case-insensitive directories (6.13) Igalia enabled casefolding support in tmpfs, allowing containers (e.g. Wine + Flatpak) to match host filesystem semantics. This removes the need for entire classes of userspace workarounds for Windows-centric applications and games.

• FUSE and VFS improvements (6.16) Added bulk dentry invalidation for FUSE servers, improving correctness and performance for user-space filesystems.

• Overlayfs case-insensitive merging (6.18) Overlayfs was enhanced to correctly merge directories on case-insensitive filesystems by introducing a casefold-aware comparison, benefiting SteamOS-style setups and containerized game environments, where overlayfs is fundamental. Together with the tmpfs change in 6.13, this significantly improves Linux compatibility with Windows-origin software stacks while keeping the solution cleanly in the kernel.

Graphics and GPUs: Performance, Stability, and Observability

GPU Memory and Performance Gains

• V3D Super Pages on Raspberry Pi (6.13) Support for 64 KB and 1 MB pages in the V3D MMU delivered measurable gains:
  • Up to 8% FPS improvement in real games
  • ~10% reduction in execution time for the respective Mesa CI job
  • Smoother emulation workloads
• Transparent Huge Pages for shmem (6.13) New kernel parameters (transparent_hugepage_shmem= and thp_shmem=) gave developers and system integrators fine-grained control over huge-page allocation, unlocking better GPU memory behavior for shmem-backed drivers.

GPU Reset Handling and User-Space Integration

Across multiple releases (6.15–6.18), Igalia substantially improved how GPU resets are detected, handled, and reported:

• DRM wedged events (6.15) introduced a generic user-space notification mechanism for GPU resets.
• Extended reset metadata (6.17) added PID and task name, enabling compositors to inform users which application caused the reset.
• False-positive timeout handling (6.17–6.18) prevented unnecessary resets by allowing drivers to report when a timeout did not represent a real GPU hang.

These changes directly improve desktop stability, user experience, and recovery behavior—especially on gaming systems and embedded GPUs.

Driver-Specific Improvements

• AMDGPU
  • Fixed long-standing race conditions in color management (notably KDE HDR/night-light flicker).
  • Improved plane handling, overlay support, VRR/MST stability.
  • Hardened ioctl paths, simplified locking, and fixed resource leaks on driver reload.
• Intel Xe
  • Expanded Alderlake support with missing hardware workarounds.
  • Improved correctness around dma-fence handling, eliminating use-after-free bugs.
• Raspberry Pi V3D
  • Major improvements to GPU reset reliability on RPi 4 and 5.
  • Added reset counters for robustness extensions.
  • Reduced lock contention and fixed race conditions in job queues.

DRM Scheduler: Foundations for the Future

The DRM scheduler received sustained attention throughout 2025:

• Performance optimizations (6.13-6.17)
  • Reduced locking overhead.
  • Optimized dma-fence merge paths to avoid allocations in common cases, lowering CPU usage on sync-heavy workloads (e.g. Vulkan compositors).
  • Added new dma-fence safe access rules and APIs which enable drivers to export fences shared via mechanism fixing an existing use-after-free condition.
• API cleanup and formalization (6.15–6.17) Igalia helped separate internal and external interfaces, reducing driver reliance on scheduler internals and preparing the ground for larger architectural improvements.
• Testing for critical infrastructure (6.16) Introduction of KUnit-based DRM scheduler tests marked a turning point, providing confidence for ongoing and future refactoring.

Memory Management and Core Kernel Improvements

Beyond graphics and scheduling, Igalia also contributed to core kernel subsystems:

• Out-of-Memory reporting (6.18) OOM diagnostics now include ZRAM and ZSWAP usage, making memory pressure analysis more accurate on modern systems.
• Allocation correctness fixes (6.18) Corrected handling of high-order allocations previously misclassified as atomic, restoring proper access to memory reserves.
• Clock / TSC fixes Improved the clock watchdog skew checks and fixed suspend/resume path when TSC is used as scheduler clock.

Reliability Through Testing and Bug Fixes

A constant background theme throughout 2025 was robustness:

• Numerous fixes driven by syzkaller/syzbot reports across filesystems, networking, memory management, media, HID, UVC, and suspend/resume paths.
• Extensive cleanups and refactoring of futex selftests (6.18), improving maintainability of one of Linux’s most performance-critical syscalls.
• Expanding coverage of misc device APIs with KUnit, specially around the use of static and dynamic minor numbers, which we also helped simplify.
• Contributions to linux-stable: not only is Igalia developing bug fixes upstream, but we also take care of ensuring relevant fixes get merged on stable kernels.

Linux Kernel Closing Thoughts

From tangible FPS gains on embedded GPUs, to safer schedulers, better diagnostics, and stronger filesystem semantics, Igalia’s 2025 contributions to the kernel made Linux faster, more predictable, and more user-friendly.

This kind of deep, upstream-focused work is what ensures the kernel can keep scaling, not just in features, but in quality.

See the full list of Igalia’s contributions for each kernel release: 6.13, 6.14, 6.15, 6.16, 6.17, 6.18.

BPF Scheduler Contributions 2025

While a large part of our work in 2025 landed directly in the upstream Linux kernel, there’s another project that deserves special attention. Throughout the year, Igalia has been a significant contributor to the sched_ext project, advancing schedulers, libraries, and tooling that allow solutions built on top of the kernel to make the most out of the infrastructure.

scx_lavd Maturity

With 228 commits, the Latency-Aware Virtual Deadline scheduler gained:

• Compute domain-aware load balancing and task stealing
• Cache-optimized data structures reducing coherence traffic
• Configurable preemption with IPI avoidance
• Futex tracing for lock-aware boosting

scx_lavd is now production-ready for latency-sensitive workloads.

CPU Bandwidth Control (cpu.max)

Implemented complete cgroup CPU bandwidth control, enabling hard CPU time limits for process groups, critical for Kubernetes, Docker, and multi-tenant cloud environments where resource isolation is mandatory.

The implementation includes a full library with quota management, throttling detection, replenish timers, and seamless integration with the scx_lavd scheduler.

Energy-Aware Scheduling

Introduced a comprehensive energy model framework for power-efficient scheduling on heterogeneous processors:

• Automatic big.LITTLE and Intel Hybrid detection
• CPU capacity and performance domain awareness
• Chip binning consideration for optimal core selection

This enables significant power savings on ARM servers (Graviton, Ampere) and modern Intel processors.

ARM64 Production Ready

Multiple fixes ensure sched_ext works reliably on ARM64:

• BPF verifier fixes for ARM64/clang combinations
• Portable implementations replacing architecture-specific builtins
• Multi-NUMA topology support

ARM servers can now run sched_ext schedulers in production.

Standardized Time API

We introduced scx_bpf_now() and migrated seven schedulers (scx_lavd, scx_bpfland, scx_flash, scx_layered, scx_mitosis, scx_rusty, scx_pair) to use consistent time handling, eliminating subtle timing bugs across platforms.

20% Smaller Binaries

Optimizing the release-tiny build profile achieved significant size reductions:

• scxtop: 20.6% smaller
• scx_bpfland: 14.0% smaller
• scx_flash: 13.8% smaller

Smaller binaries mean faster deployment and better suitability for embedded systems.

scx Closing Thoughts

sched_ext represents a major shift in how Linux scheduling can evolve. In 2025, Igalia focused on making it practical and production-ready—from kernel hardening to real-world schedulers, energy awareness, and cloud-grade resource control.

As adoption grows in 2026, we look forward to continuing this work with the broader community.

Final Remarks

Igalia’s 2025 kernel and sched_ext contributions demonstrate the value of sustained upstream work paired with practical engineering. By improving core kernel subsystems and enabling new scheduling models through sched_ext, these efforts help Linux remain performant, reliable, and adaptable at scale.

We look forward to continuing this work with the community in the years ahead.