XDC 2026 - X.Org Developer's Conference

28 Sep 2026, 08:00 → 30 Sep 2026, 18:45 America/Toronto

Monday, 28 September

08:00 → 09:00 Breakfast and Registration

09:00 → 16:50 Main Track

09:00 Monday Opening Session

09:15 Is it time for Vulkan Gallium?

When Vulkan 1.0 first came out a decade ago, writing Vulkan drivers was fun. You just mapped API bits to HW bits and off you go! In 2026, with Vulkan 1.4 and hundreds of extensions, it's not so simple. There is legacy cruft we all have to carry. There are 3 versions of some enums which have to be remapped by someone. There are duplicate entrypoints and queries everywhere.

In the OpenGL world, we have an answer for this: Gallium. Is it time for a Gallium for Vulkan? In this presentation, Faith will talk about why she thinks it's time, what that layer would look like, and what it would mean for the Vulkan drivers that exist in the tree today.

Speaker: Dr Faith Ekstrand (Collabora)

10:05 Handling XR Displays in the Linux Graphics Stack

In the Linux DRM subsystem, an XR device display is currently exposed as a single, aggregated display. However, treating an XR device like a traditional flat monitor completely breaks the human experience.

Physically, an XR device consists of two distinct displays (one for each eye). Simply pushing standard 2D desktop frames to this aggregated screen results in an unviewable, disorienting output. To produce an image that a human eye can actually process through the headset's optics, the output requires heavy GL/Vulkan-based transformations. These transformations must account for stereoscopic rendering, lens distortion correction (barrel distortion, chromatic aberration), and the physical focal planes of the hardware.

This short talk will outline the disconnect between how DRM sees an XR display and what the human eye physically needs. The primary goal is to trigger an open discussion on the architectural path forward:

• Should we add special properties to such display so traditional DRM clients (fb emulation, compositor, ...) avoids considering them as an output ?
• How should we properly expose the physical lens and plane characteristics of XR hardware through DRM?
• Should the compositor bear the full weight of these rendering transformations, or is there a better abstraction?
• How do we standardize the handling of XR displays across the Linux graphics stack to make native XR a reality?

Speakers: Neil Armstrong (Linaro) , Mr Nie Jun (Linaro)

10:30 Next Generation Display Walls on Linux

Display walls, arrays of displays assembled to look like one large screen, have historically been driven by an X server and are typically supported via display technology provided by a vendor's X driver. As the ecosystem migrates to Wayland this architecture is no longer available and a new design must take shape. For this reason, NVIDIA now recommends an explicit Vulkan VK_KHR_display design where applications directly drive displays for more fine-grained control.

This talk will cover how display walls are used, why the X-based design was originally chosen, and why Vulkan Direct 2 Display can provide a better approach. We will discuss Display Config Server, a new open source solution to display wall configuration and persistence, along with future work to help support the next generation of display walls on Linux.

Speaker: Austin Shafer (NVIDIA)

10:50 Break

11:20 LLM inference on the Raspberry Pi 5 via Vulkan

The Raspberry Pi 5's Broadcom V3D 7.1 GPU was designed for graphics
workloads, but the wave of on-device LLM frameworks now directs pure
compute workloads at the V3DV Vulkan driver. This talk reports what
we learned extending V3DV for these workloads since early 2026.

ML inference stresses the driver in ways graphics never does: thousands
of tiny buffer fills and copies per token, heavy buffer-object allocation
against V3D's 4 GB memory ceiling, shaders with high register pressure,
and a dependence on fast fp16 support.

We walk through the driver changes this new workload required — enough that
it is now possible to run open-weight models with inference frameworks
such as Ollama/llama.cpp and LiteRT-LM.

Finally, the talk discusses future work and the challenges that remain
to run inference on V3DV.

Speaker: José María Casanova Crespo (Igalia)

12:10 nocl: OpenCL on CUDA

Nocl is a gallium driver for use in rusticl to have an Open-Source OpenCL implementation on top of CUDA.

People keep asking about this little side project of mine, so I want to talk about what's the status of the project, what are the difficulties working on it.

I'll go into the overall structure of the project, features there are more interesting to implement, what's still missing before I'm happy enough about it.

Speaker: Karol Herbst (Red Hat, Nouveau)

12:30 Lunch

14:00 SSA-based Register Allocation for Intel GPUs

Intel’s GPUs feature an unusual explicit SIMD instruction set presenting challenges for just-in-time shader compilers. Naïvely modelling Intel’s SIMD architecture artificially increases register pressure and requires expensive register allocation algorithms based on graph colouring. To improve code quality while decreasing compile time, our compiler “Jay” eschews the hardware’s native SIMD in favour of contemporary GPUs’ simpler SIMT model. Our nonlinear remapping of logical SIMT registers onto the physical SIMD register file facilitates near-linear time register allocation with an SSA-based tree scan allocator and a decoupled spiller. Compared to Intel’s existing non-SSA Linux shader compiler, our compiler reduces spilling on a collection of game shaders by 98%. Jay demonstrates the feasibility and profitability of SSA register allocation even for irregular GPU architectures and provides the foundation for Intel’s future Linux shader compilers

Speaker: Alyssa Rosenzweig (Intel)

14:50 Optimizing the Panfrost Gallium driver

The performance of the Panfrost driver for Arm's Mali GPUs has improved significantly over the past year, driven by increasing industry adoption. This talk will first cover the evolution of tracing tools in Mesa (Perfetto) and their integration into Panfrost and then present the resulting optimizations (blits, draw calls, Transparent Huge Pages, Transaction Elimination, etc).

Speaker: Loïc Molinari (Collabora Ltd)

15:15 Demo: Gamma, a ray tracing debugger for Mesa drivers

Almost 6 years after the release VK_KHR_acceleration_structure, ray tracing is still an area in graphics with really bad tooling. Gamma tries to solve this by providing a framework for writing driver specific visualizers. Konstantin will showcase the capabilities using RADV as an example, and how support for other drivers can be added.

Speaker: Konstantin Seurer

15:25 Break

16:00 Firefox + Steam Deck: Seamless experience across two compositors

Supporting a major web browser on the Steam Deck brings an exciting challenge because of the unique dual-compositor architecture: Gamescope for game mode and KWin for desktop mode.

This talk covers our ongoing efforts to transition Firefox to use Wayland natively under Gamescope with wl_subcompositor, aiming to surpass the limitations of the current X11 implementation. We will share our progress on achieving touch and input parity, improving container integrations like async D-Bus handling, and integrating system-wide HDR video support.

Speaker: Eri Pazos Pérez (Igalia)

16:25 Bringing Linux DRM Display Panel support in the modern age

Since the introduction of the first Samsung DSI panel, the Linux DRM panel
API has been a crucial piece of software for enabling displays across
diverse architectures, but it has not evolved alongside modern graphics stacks.
Currently, the API lacks atomic DRM API support and the ability to adapt
power setups during mode changes.
Furthermore, it fails to support advanced Display Driver IC (DDIC) features
that modern hardware heavily relies on, including:
- Standby and advanced power states
- Advanced color management
- Dynamic rate switching
- Command mode self-refresh

This lack of evolution has led to severe fragmentation between upstream
and vendor downstream trees for advanced devices support, creating a heavy
maintenance burden and making native hardware support incredibly difficult.

The goal would be to outline these architectural limitations and trigger a
hallway discussion on how to collaboratively modernize the panel API.

Speaker: Neil Armstrong (Linaro)

10:05 → 11:35 Workshop, Meeting or Hacking session

10:05 Workshop: Vulkan "Gallium"

Following up on Faith's talk, this is an opportunity to brainstorm and hear thoughts from other Vulkan driver maintainers.

Speaker: Dr Faith Ekstrand (Collabora)

16:50 → 17:20 Lightning Talks

16:50 Vulkan CTS uses too much system memory? No problem

Vulkan CTS memory requirements had been steadily increasing over many years until reaching a breaking point when it started creating issues for some Mesa CI runners. We studied the problem, understood the root cause and decreased peak memory needs from 900 MBs to 300 MBs in our test builds. This talk is a quick postmortem that also helps set expectations for CTS users.

Speaker: Ricardo Garcia (Igalia, S.L.)

16:55 Turning Driver Bugs into Vulkan CTS Tests

Fixing a Vulkan driver bug is important, but making sure it never returns is just as important. This lightning talk will briefly describe the process of turning a real driver bug into a Vulkan CTS test. I will share a few examples of challenges encountered while reproducing bugs in a small, reliable conformance test, and explain why a straightforward test often isn't enough to expose the original issue. The talk will conclude with a few practical lessons learned from contributing bug-fix regression tests to Vulkan CTS.

Speaker: Madeeha Javed (Igalia)

17:00 CI-Tron for kernel development

When several new boards could not fit my traditional setup, I had to revert to use of the CI-Tron for automation of those boards. This lightining talk shows the use of CI-Tron for the kernel developent and maintainer duties, emphasising its usage out of the traditional CI area.

Speaker: Dmitry Baryshkov (Qualcomm)

17:05 Finally getting rid of TGSI?

It's been well over a decade since NIR landed upstream in Mesa. Since then, a lot of people have worked hard to get rid of TGSI. While there's still a few road blocks left, we're getting close to the home-stretch.

This talk will try to answer the question: How can we finally get rid of TGSI in Mesa?

Speaker: Erik Faye-Lund (Arm)

17:10 rusticl status update

Short status update about new OpenCL features supported, features work in progress, changes in driver status and what the priorities are going forward.

Speaker: Karol Herbst (Red Hat, Nouveau)

17:20 → 17:25 Monday Closing Session

19:00 → 23:00 Social Event: Welcome Reception, sponsored by Arm & Collabora

Tuesday, 29 September

08:00 → 09:00 Breakfast and Registration

09:00 → 16:50 Main Track

09:15 Apple M3 GPU reverse engineering progress.

A small group of people has been at work reversing the GPU in the M3 SoC and in this talk we will talk about the progress we've made so far.
We will talk about how the HW differs from previous generations and what is required to port the driver.
Finally, we will discuss the status of the porting work for the userspace and kernel drivers.

Speakers: Anna Maniscalco (Valve) , Alyssa Milburn, Evan Tang (Codeweavers)

10:05 Error Handling on Atomic Commit Failure

Problem Statement
Today, when an atomic commit fails, userspace typically receives only a generic error such as -EINVAL, with no indication of the underlying cause. As a result, compositors cannot determine why the commit failed or apply appropriate corrective actions. A common example is a bandwidth-related failure, where the requested bpc exceeds the available link bandwidth. Since the failure reason is not propagated to userspace, the compositor must rely on kernel logs to diagnose the issue and infer that the bpc should be reduced before retrying the atomic commit.

Solution
The goal is to provide compositors with sufficient information to understand why an atomic commit failed and enable targeted fallback mechanisms. In the bandwidth example above, the kernel reports the reason for the failure, allowing the compositor to identify the bandwidth limitation, reduce the bpc accordingly, and retry the atomic commit with a more suitable configuration.

The proposed DRM/KMS UAPI for atomic commit failure reporting repurposes the reserved u64 field in struct drm_mode_atomic, passed as part of the atomic_commit ioctl, to return detailed failure information to userspace. As part of the compositor implementation, this information is decoded to identify the specific reason for an atomic commit failure. Based on the reported failure, the compositor will implement targeted fallback logic and intelligently retry the atomic commit with a more suitable configuration wherever possible.

Atomic Commit Failure Codes Reported by Kernel
The current implementation defines the following common atomic commit failure codes, with the flexibility to extend the list as new failure scenarios are identified.
• DRM_MODE_ATOMIC_UNSPECIFIED_ERROR – Generic error when no specific failure reason is available.
• DRM_MODE_ATOMIC_INVALID_API_USAGE – The atomic commit failed due to invalid use of the DRM atomic API (e.g., missing atomic capability, invalid flags, or incompatible options).
• DRM_MODE_ATOMIC_NEED_FULL_MODESET – The requested update requires a full modeset.
• DRM_MODE_ATOMIC_ASYNC_PROP_CHANGED – A property was modified during an asynchronous page flip.
• DRM_MODE_ATOMIC_SCANOUT_BW – The requested display configuration exceeds the available scanout bandwidth (e.g., resolution, refresh rate, or color depth).
• DRM_MODE_ATOMIC_CONNECTOR_BW – The requested configuration exceeds the available bandwidth of the display connector or link.
• DRM_MODE_ATOMIC_PIPE_BW – The display pipeline cannot support the requested configuration due to pipe or scaler limitations.
• DRM_MODE_ATOMIC_MEMORY_DOMAIN – The requested configuration exceeds memory or bandwidth constraints not covered by the other bandwidth-related errors.
• DRM_MODE_ATOMIC_SPEC_VIOLATION – The requested configuration violates a hardware-specific capability or specification limitation.

References
2025 Display Next Hackfest https://hackmd.io/f3bDn3kyRUalLn4LbMfCVQ#Commit-Failure-Feedback
Kernel https://patchwork.freedesktop.org/series/152275/
Mutter https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/5022
IGT https://patchwork.freedesktop.org/series/153330/
Libdrm https://gitlab.freedesktop.org/mesa/libdrm/-/merge_requests/450
KWIN https://invent.kde.org/plasma/kwin/-/merge_requests/8991

Speaker: Ramya Krishna Yella (Intel)

10:30 Panthor status update

Annual report on the status of Panthor and what has been accomplished over the year. We also want to update the community on plans for the next year and the list of features we are going to work on.

Speakers: Boris Brezillon (Collabora) , Liviu Dudau (Arm Ltd) , Karunika Choo (Arm Ltd)

10:50 Break

11:20 Kraid: A new compiler for Panfrost

The compiler the panfrost drivers currently use for Bifrost and later hardware is starting to show its age. It was originally developed as a Bifrost compiler and Valhall support was bolted on as an afterthought. This summer, a few of us at Arm and Collabora have been building a brand new compiler for Valhall and later hardware. In this presentation, we'll talk about the new compiler, the rational for rewriting instead of fixing the old one, and our plans for the Panfrost compiler stack going forwards.

Speakers: Lorenzo Rossi, Dr Faith Ekstrand (Collabora)

12:10 Better render passes in PanVK for moar FPS

Earlier this year, we substantially reworked the render pass abstraction used by the PanVK driver. Previously, it was based on what Alyssa had written for the OpenGL driver which was designed around an immediate-mode API. With Vulkan, we have more information and can do better. In this talk, Faith will talk about the over-all design and philosphy of the new abstraction and how it's helped us get massive speed-ups in certain MSAA benchmarks.

Speaker: Dr Faith Ekstrand (Collabora)

12:30 Lunch

14:00 Foveated rendering on Turnip

Eye-tracked foveated rendering is a technique for accelerating rendering of virtual reality content by tracking where the user's eyes are looking and rendering the parts of the screen near the user's gaze at a higher resolution than everything else. As part of efforts for the Steam Frame, we reimplemented existing techniques for foveated rendering on Qualcomm Adreno GPUs in the Turnip open-source Vulkan driver and further pushed the envelope by designing and implementing new Vulkan extensions to bring foveated rendering to more content. This talk will go over how foveated rendering works in Turnip through VK_EXT_fragment_density_map and related extensions, various extensions and driver optimizations to further improve performance and visual quality, and future directions for improvement.

Speaker: Connor Abbott (Valve)

14:50 MSM graphics status report and roadmap

Since the last XDC, we have enabled adreno gen8 (a830, a840, x2-90, etc) in mesa (gl/cl/vk) and upstream kernel, in addition to continuing to backfill support for a6xx and a7xx devices.. with more to come. And we continue to shift-left in terms of enabling new hw prior toshipping, starting with x2-90.

In addition, new features have been added (PERFCNTR_CONFIG, rusticl enabled by default, etc).. again with more to come. Not to mention, enabling new platforms in CI.

On the display side, we've enabled quad-pipe support (enabling higher resolutions), virtual planes, gamma correction, and re-worked UBWC configuration to have a single source of truth across all drivers.

This presentation will give a recap of progress since XDC2025, and an overview of what's to come.

Speakers: Rob Clark (Qualcomm) , Dmitry Baryshkov (Qualcomm)

15:15 Demo: Turnip without Root

Turnip is one of Mesa's few drivers that has support for multiple kernel drivers, including the upstream MSM kernel driver and downstream KGSL kernel driver. This gives it the interesting ability to be able to run on devices that run Linux as well as unmodified android phones, which are typically pretty locked down.

This talk will be a quick crash course for anyone interested in getting involved in Turnip's development, showing what tools are available to begin development with a completely unmodified stock android device.

Speaker: Lucas Fryzek (Igalia S.L.)

15:25 Break

16:00 Last Year of Turnip

The devs behind Turnip have been hard at work improving the driver. You may have heard that Turnip is being used for some pretty serious™️ gaming now. To support that we've been working on adding extensions, improving performance, and adding support for new devices.

In this presentation we are going to give you an update on the current state of Turnip, and give a little more details on some of the cool new features in Turnip like the auto-tuner, support for new Adreno gen 8 devices, and what's required in Turnip to run real games.

Speakers: Lucas Fryzek (Igalia S.L.) , Karmjit Mahil (Igalia S.L.)

16:25 KosmicKrisp production ready!

KosmicKrisp status update on features, performance and developer tips and tricks.

Speaker: Aitor Camacho Larrondo (LunarG)

09:10 → 10:40 Workshop, Meeting or Hacking session

09:10 Workshop: Mesa CI - What still needs to be done, and how to get there?

The Mesa CI pipeline is complex and has many issues that are being addressed (see presentation "Addressing Mesa CI pain points (2nd edition): what we've done, and where we are going").

This workshop will be dedicated to discussing outstanding pain points from the presentation, so that we (the CI developers) can make sure you (the CI users = Mesa developers) agree on what these pain points are, and what our plan to address them should be.

The currently known pain points are:
- Reliability of the Marge workflow (unavailable runners, flaky jobs, ...)
- Long waiting times to get your MR tested and landed
- Requirement to use an external script (GitLab web UI missing some buttons to run just the jobs we want)
- Reproducing CI jobs locally
- Updating job expectations (collating results from multiple runs, reducing the size of the flakes lists, failure rate of different tests, ...)
- GPU hangs: how to prevent merging code that sometimes hang the GPU, and how to minimize impact of flaky hangs once the regression is merged
- Game traces: increasing coverage, and access to the game traces & artifacts
- And probably more, so come tell us what is your pain point!

Speaker: Martin Roukala (né Peres) (MuPuF TMI / Valve contractor)

16:50 → 17:20 Lightning Talks

16:50 etnaviv: good things take time

Some things are worth the wait. After a long, patient climb, the etnaviv project
reached two milestones this year that once felt a long way off.

This lightning talk looks at where the driver finally caught up on conformance, and
at a new capability that opens the door to a whole class of workloads etnaviv could
not run before.

Years in the making, and worth every step

Speaker: Christian Gmeiner (Igalia)

16:55 v3d/v3dv: status update from last XDC

The V3D (OpenGL) and V3DV (Vulkan) drivers power the Broadcom GPU found in the Raspberry Pi 4 and 5.

In this lightning talk we will go through a high-level tour of the latest updates to these drivers that we deliveredwhat things have been done on them: new extensions and features, performance improvements in different paths, refactors, CI, and so on.

After this talk you will have a better understanding on what happened in the RPi GPU driver development in the last year.

Speaker: Mr Juan A. Suarez (Igalia, S.L.)

17:00 Supporting workgroups where there aren't any

Workgroups are a concept which allow multiple SIMD waves of shaders to run together and share some memory. API features such as compute and mesh shaders expect the driver to support workgroups. Modern hardware typically supports it, but... What if you want to run workgroups on hardware that doesn't really support it, for example you want to run mesh shaders on NVidia? Or maybe you want to support larger workgroups on older hardware that has an upper limit on the workgroup size?

The new compiler pass nir_lower_workgroup_size was invented exactly for this purpose. Your driver can now support workgroups where there aren't any, or support larger workgroups when the HW can't.

In this lightning talk I'll present what the challenge is with "emulating" workgroups; how we solved it, and how we've used it to implement NVK mesh shaders, to support larger compute workgroups on old GPUs on RADV, and even to find ray tracing issues.

Speaker: Timur Kristóf (Valve)

17:05 Resolving game bugs using retry faults

Modern games and game engines are getting more and more complicated, and show a lot of creativity in inventing new ways to implement memory management issues. Use after free, use before alloc, you name it. You may have seen GPU hangs thanks to page faults during gameplay.

In this lightning talk, I'd like to present a proposal to deal with this type of problems on modern AMD GPUs on Linux, called retry faults. This hardware feature allows the kernel to resolve page faults and let the game continue. We can also use this to implement some features of the VK_KHR_device_fault extension.

Speaker: Timur Kristóf (Valve)

17:10 drm/dp: statups update of the common kernel framework.

On the last XDC the plan for the common DisplayPort framework in DRM was announced. Thihs lightining talk provides a (small) status update over the past year.

Speaker: Dmitry Baryshkov (Qualcomm)

17:20 → 17:25 Tuesday Closing Session

Wednesday, 30 September

08:00 → 09:00 Breakfast and Registration

09:00 → 16:30 Main Track

09:00 Wednesday Opening Session

09:15 PowerVR: A Year of Progress

Over the past year the PowerVR driver has made significant progress, from passing Vulkan 1.2 conformance to enabling OpenGL (ES) support via Zink, Wayland support, Mesa CI integration, improved developer tooling and adding support for additional platforms.

This talk will cover the advances that have been made since last XDC, discuss the current state of the PowerVR driver and outline the roadmap for future development. In addition, it will also cover the ongoing work on the compiler backend (PCO), including some of the challenges and design decisions involved in working with the Rogue ISA.

Speakers: Simon Perretta (Imagination Technologies) , Frank Binns (Imagination Technologies)

10:05 From KFD to DRM SVM: Toward a Unified Memory Model in DRM

Shared Virtual Memory (SVM) enables a unified virtual address space for heterogeneous computing, but existing implementations remain outside the upstream DRM framework and face scalability challenges. In particular, KFD SVM relies on mmap read/write locks for synchronization, which tightly couples driver-level behavior with the system memory management and increases overall design complexity.
At XDC 2025, an initial DRM SVM framework was introduced based on Intel Xe. In this talk, we build that foundation by evolving SVM into a unified DRM-based abstraction and demonstrating it on AMDGPU.
We highlight several key architectural improvements. First, DRM SVM adopts a significantly simplified synchronization model, avoiding heavy mmap locking. Second, it is designed with native large page support, improving efficiency without invasive changes. Third, it introduces a cleaner abstraction by separating memory attributes from the physical layer, combined with a range-based model (up to 2MB granularity).
We also demonstrate both fault-driven (XNACK-on)[1] and non-fault-driven (XNACK-off) [2][3] execution models and discuss ongoing work to extend DRM SVM beyond its current single-device scope toward multi-device support[4].
This work advances DRM SVM toward a scalable, vendor-neutral, and upstream-aligned memory model.

[1] https://lore.kernel.org/dri-devel/20260612090928.29682-1-ray.huang@amd.com/
[2] https://lore.kernel.org/amd-gfx/20260519092313.3115848-1-honglei1.huang@amd.com/
[3] https://lore.kernel.org/amd-gfx/20260605075340.20199-1-Junhua.Shen@amd.com/
[4] https://lore.kernel.org/dri-devel/20260603065620.2555316-1-honglei1.huang@amd.com/

Speaker: Ray Huang (AMD)

10:30 Learning kernel development through fixing old AMD GPUs on Linux

At XDC 2025 I promised that old AMD GPUs would work great on Linux, starting from GCN 1 up to GCN 4. In this talk, I'd like to present the progress on that work and what I learned from it.

In the current economic situation of our world, people may have to use GPUs for longer, and replace them less often. And when an old GPU is replaced, it doesn’t disappear, it goes to somebody who upgrades an even older GPU. Eventually it will reach somebody that can’t afford a better one. My goal with this work is to make Linux gaming a good experience also for those who use old AMD GPUs, and learn Linux kernel development in the process.

What did this work entail?

I'll talk about implementing various display features, VCE support, DRM format modifiers, Vulkan, improved GPU hang recovery, sparse bindings, fixing memory management issues, power management bugs and making some GPUs boot that previously never worked on Linux.

With that, GCN GPUs can now run a modern Linux graphics stack using the amdgpu kernel driver and the RADV Vulkan driver.

Speaker: Timur Kristóf (Valve)

10:50 Break

11:20 NVK in 2026

What's new with everyone's favorite open source Vulkan driver for Nvidia GPUs? A bunch of stuff! Learn more about the latest in nvk technology -- compression, memory copies, mesh shaders, and more!

Speaker: Mel Henning

12:10 Upstreaming Tyr: a DRM GPU kernel driver in Rust

The Tyr project aims to port the existing DRM GPU kernel driver, Panthor, to Rust. Upstream Tyr is still very much a work-in-progress: it will probe as a platform device driver and can read and report on its GPU registers, but the rest of Tyr remains in a state of flux. Moving Tyr upstream has required us to test, adapt to, and contribute to the larger Rust ecosystem that is developing around it in the kernel.

In this talk, I will walk through the initial stage of booting the microcontroller (MCU) in a Mali-G610 GPU to demonstrate how Tyr is using some of the newest Rust kernel abstractions for graphics. In particular, I will discuss how Tyr uses DRM GEM shared-memory buffer objects in conjunction with the GPU virtual memory manager to load the MCU firmware and start up the command-stream frontend for the GPU.

Speaker: Deborah Brouwer (Collabora)

12:30 Lunch

14:30 Addressing Mesa CI pain points (2nd edition): what we've done, and where we are going

Mesa CI has one of the most complex CI pipelines. While this is great for test coverage, this also brings challenges in infrastructure, usability, and sustainability. In this second edition of the talk, we will present what we think works, what we've done over the past year, what still needs improvement, and what is currently on our roadmap.

We've submitted a workshop proposal to discuss these issues further and agree on the roadmap for the next 12 months. Come watch the talk and join the workshop to let us know if we've missed any pain point and influence these plans!

Speakers: Martin Roukala (né Peres) (MuPuF TMI / Valve contractor) , Eric Engestrom (Mesa)

14:55 Display Next Hackfest 2026: What we hacked on in Nice

A recap of this year's Display Next Hackfest, held in Nice right after Embedded Recipes. Topics ranged from finally getting backlight control working through KMS, to AMD FreeSync Premium Pro (aka Source-Based Tone Mapping) landing support on DP and HDMI, to DisplayID gradually taking over from EDID. We also dug into the perennial pain of frame timing on high-refresh-rate displays, merged a new Wayland protocol for multi-device dmabuf feedback, made progress on hot-pluggable DRM bridges, and squashed some gnarly slow-atomic-commit bugs on AMD that were blocking overlay planes by default. This talk walks through what got discussed, what got decided, and what's actually shipping.

Speaker: Daniel Stone (Collabora)

15:20 Demo: Interactive HDCP Diagnostic Tool for Linux DRM/KMS stack.

HDCP (High Bandwidth Digital Content Protection) failures during real-world playback are difficult to reproduce and harder to triage. When protected content breaks on a user’s machine, there is rarely a quick way to tell whether the fault lies in the kernel driver or in user space or in the display link itself. Such failures are often intermittent, they surface only after a session has been active for some time, and they depend on the monitor, cable, and content-type combination and display configuration in use which makes them easy to miss with a conventional pass/fail test (eg: kms_content_protection IGT) that runs once and exits.

HDCP Tool is an IGT (IGT GPU Tools) command line tool designed to identify the early issues that might occur on a Linux users’ machine. Its primary purpose is to confirm that content protection stays enabled for the full duration of an active playback session. By continuously polling the link it makes integrity failures easy to identify the moment they occur clearly showing whether the protected link stayed up and, if it dropped, exactly when. It also supports compliance validation while sessions are active, letting HDCP behavior be exercised and confirmed under realistic conditions.

Current User Flow:
The tool runs as an interactive, menu-driven application rather than a one-shot pass/fail test. Once started, it displays a menu on the connected screen and waits for operator input. Using single-key commands, the user can request a specific protection mode, query the status, or end the session. Each command takes effect immediately, so content protection can be enabled, changed, or disabled while the display session remains active.

1. Get HDCP Information
   Retrieves and displays a detailed per-connector summary, including the encoder, connection status, connector type, sink device HDCP capabilities, current protection status, and active content type.
2. Enable HDCP 1.4
   Initiates HDCP 1.4 protection by setting the Content Protection property to DESIRED and configuring the Content Type to 0.
3. Enable HDCP 2.2 (Type 0)
   Requests HDCP 2.2 protection for Type 0 content by setting Content Protection = DESIRED and Content Type = 0.
4. Enable HDCP 2.2 (Type 1)
   Requests HDCP 2.2 protection for Type 1 content by setting Content Protection = DESIRED and Content Type = 1.
5. Disable HDCP
   Disables content protection by setting the Content Protection property to UNDESIRED, thereby removing HDCP enforcement.
   Q. Terminates the application session and releases all allocated display resources.

The overlay is also helpful to color vision deficiency operators: because every mode and status is shown as on-screen text (mode name plus an Enabled/Desired/Disabled string), no critical information depends on distinguishing the background colors.

Future Plans of Tool Enhancement:
1. Improvements are planned for DP-MST setups to better handle multiple displays.
2. Support for display hot-plug events (hpds) will allow testing when monitors are connected or disconnected during playback.
3. Enhanced diagnostics, including detailed HDCP state-transition logging and failure reporting.

Speaker: santhosh reddy SANTHOSH GUDDATI

15:30 Break

16:05 State of the X.Org Foundation

State of the X.Org Foundation

Speaker: Lyude Paul (Red Hat)

09:10 → 10:40 Workshop, Meeting or Hacking session

09:10 Workshop: Towards a governance model for Mesa

Mesa has for the longest time functioned without a formal governance model. And while just relying on forming informal consensus functions well most of the time, there are times when we end up with compromises that nobody likes.

So let's have a sit down and discuss options for putting in place a formal governance model.

Speakers: Erik Faye-Lund (Arm) , Alyssa Rosenzweig (Intel)

16:30 → 17:15 Lightning Talks

16:30 Introducing the Wayland Content Frame Rate Protocol

Problem Statement
Compositors are unaware of the media content frame rate and therefore present frames using the display's default refresh cadence. This mismatch leads to irregular frame timing, causing judder during low-frame-rate video playback (e.g., 24/30 fps) on both fixed-refresh and VRR displays. A familiar example is 3:2 pulldown, where 24 fps content is displayed on a 60 Hz panel with alternating 3- and 2-refresh frame durations, resulting in uneven motion. Figure 1 illustrates a similar issue, showing how 30 fps content is presented with irregular frame timing on a 40–60 Hz VRR display.

Figure 1
https://github.com/k2naveen/xdc-2026/blob/main/media-playback-frame-judder.png

Solution
To address this, we propose the wp-content-frame-rate-v1 [1] Wayland protocol, enabling media players to communicate the content frame rate to the compositor. The compositor [2] uses this information to apply Low Frame Rate Compensation (LFC) on VRR displays by selecting the lowest stable refresh-rate multiple of the content frame rate, or to switch to a matching supported display mode on fixed-refresh displays, delivering smooth, judder-free playback.

[1] https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/518
[2] https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/5091

Speaker: Mr Naveen Kumar (Intel Corporation)

16:35 Navigating the Tunnel : DisplayPort over USB4/TBT

A familiar failure motivates this talk: two high-resolution displays on one USB4/Thunderbolt dock, each working alone but not together, because nothing arbitrates the shared link.

A DisplayPort monitor on such a dock looks like an ordinary connector to userspace, but in the kernel the work is split across two subsystems that never call each other. The graphics driver (i915/xe plus the DRM DP tunnel helpers) owns the DP source, mode validation, and atomic state. The USB4/Thunderbolt connection manager (drivers/thunderbolt, or controller firmware) owns the physical link and the bandwidth of every tunnel (i.e. DisplayPort, PCIe, USB3) sharing it. The two domains coordinate only through the DisplayPort Bandwidth Allocation protocol: a small set of DPCD registers carried over AUX.

From that starting point the full bandwidth lifecycle unfolds: how available bandwidth is estimated, how a stream's requirement is computed, how the group budget is enforced during the atomic check, how the request is issued at commit and answered by the connection manager, and how the state is updated at runtime.

Overview

Outline

1. DP over USB4/Thunderbolt, and the subsystem split
2. What DP tunneling is, and how it appears to userspace.
3. The split of responsibility: DRM/KMS vs. drivers/thunderbolt.
4. The Bandwidth Allocation protocol
5. The DPCD register interface and how a request reaches the connection manager.
6. How the DRM DP tunnel helpers bridge the two domains.
7. Case study: two displays on one dock
8. Walkthrough of a dock bandwidth exhaustion scenario.
9. Estimation, requests, and atomic-state representation in i915/xe.
10. Hotplug
11. Dynamic recalculation on hotplug and state changes.
12. Future work and upstreaming
13. Panel Replay bandwidth optimization.
14. Asymmetric USB4 links and UHBR.
15. Validation strategies.

Upstream contributor : Imre Deak imre.deak@intel.com

Speaker: Kunal Joshi (intel)

16:40 Testing a browser on a real Wayland compositor (and why we all want this standardized)

Chromium runs thousands of interactive UI tests that need synthesized input. On Wayland
there's no portable way to do that, and the reference compositor (weston) doesn't implement
enough of the real protocol surface to be representative. So we forked mutter, taught it
Chromium's ui-controls protocol, and wired it into our CI to run interactive tests on a
real compositor for both pre- and post-submit. This lightning talk covers what that took,
what broke, and why every app project shouldn't have to reinvent this, closing with a pitch
to standardize cross-compositor application testing (cf. wayland-protocols #230).

Speaker: Orko Garai (Igalia)

16:45 Wayland vs X.org latency comparison

Wayland input latency is a topic discussed in the Linux graphics community and claims that “Wayland adds latency” have been repeated in the past. This talk explores end-to-end latency comparison in an automated A/B testing setup designed to produce more rigorous and reproducible measurements. The session focuses on comparative evaluation across multiple compositors or window managers, high-level display configurations, and measurement methods, with the goal of giving compositor and driver developers a fairer basis for discussing latency.

Speaker: Kamil Łysik (NVIDIA)

16:50 Workshop recap: Vulkan "Gallium"

Speaker: Faith Ekstrand (Collabora)

16:55 Workshop recap: Mesa CI

Speaker: Martin Roukala (né Peres) (MuPuF TMI / Valve contractor)

17:00 Workshop recap: Towards a governance model for Mesa

Speakers: Alyssa Rosenzweig (Intel) , Erik Faye-Lund (Arm)

17:15 → 17:25 XDC 2026 Closing Session