Weston 16.0.1 puts Intel i915 back on its native Wayland backend after kernel regression
The Wayland project shipped Weston 16.0.1 this month, a bug-fix release that quietly restores Intel's i915 GPU driver to Weston's native DRM backend, where it had broken on fairly recent Linux kernels. Not the flashiest of updates. But if you run Intel graphics on a Linux desktop, this is the one that actually matters.
Weston is the Wayland project's own reference compositor, the baseline other desktops build toward, not a household name like KWin or Mutter. Point releases like this are its maintenance rhythm: no new features, just the fixes that piled up. This one bundles roughly two months' worth, spanning 17 commits from 8 contributors.
The maintainer's note doesn't sugarcoat it.
"A few fixes have been piling over a few months, including one that allows i915 to run back again on the native drm-backend, which was causing some issues on fairly newer kernels (related to BACKGROUND_CRTC property)," they wrote on the wayland-devel list.
What actually got fixed
The headline fix circles back to that BACKGROUND_CRTC property, a CRTC-level thing introduced in the Linux 7.1 kernel that lets a compositor offload a solid background color straight to the display controller. Somewhere along the way, handling it on newer kernels went sideways and i915 native compositing stopped working entirely.
The fix is mostly state-management plumbing. Naveen Kumar moved the CRTC background color into drm_output_state, giving the per-output state struct ownership of it. Michael Olbrich tightened runtime mode changes. And Pekka Paalanen did the boring-but-vital work of framebuffer lifecycle hygiene. Paalanen is the kind of contributor whose commits you don't read about but absolutely notice when they're gone. His "turn destroy_dmabuf into unref" swap, for instance, stops a shared DMA-BUF framebuffer from being freed while still referenced elsewhere, a classic route to GPU hangs.
Beyond the i915 rescue, there's a cluster of smaller wins floating around in here. Derek Foreman cleaned up the tracing macros and fixed a stray trace event that could corrupt captures from profiling tools like Perfetto. He also corrected the wl_tearing protocol, the handshake that tells a client exactly when a surface got presented so it can render the next frame without clobbering one still on screen. For someone running a high-refresh-rate panel, that handshake actually matters.
Leandro Ribeiro did a color-format refactor, splitting what format an output prefers from the one actually committed, plus a null-pointer guard in the Lua shell. The latter sounds trivial until you picture a crash on an embedded device that just wanted to click into an app.
HDR detection is one of the smaller fixes that quietly affects real hardware. Tom Pollard bumped the allowed dependency to libdisplay-info 0.4.0, and that matters for people chasing HDR. Some laptop OLEDs, including certain Samsung ATNA-series panels, stash HDR static metadata inside a DisplayID 2.0 extension block rather than the usual CTA-861 location. libdisplay-info only learned to read that spot in 0.4.0. Older versions simply report no HDR support, so your compositor never offers the toggle at all, regardless of whether you're on GNOME or KDE. Allowing the newer library restores detection for those screens.
It's a decent reminder that HDR "doesn't work" is frequently a metadata-parsing problem, not a compositor bug.
Why point releases still count
On the surface, a release with no new features is hard to justify. It isn't, though. Weston's cadence is deliberate: a large feature cycle (16.0 landed in mid-July) followed by occasional maintenance bumps, the opposite of the rapid iteration you get from wlroots-based compositors like Hyprland. Embedded and IoT vendors in particular ship Weston from distro trees and value that stability over novelty.
Keep in mind that this is a point release, so all of 16.0's new HDR and color work is already here. 16.0.1 just stops it from quietly breaking. The i915 fix is a textbook case. Compositor and kernel are now so tightly coupled that a DRM/i915 change in a newer kernel can silently break compositing, and the only path back to end users is one of these small, tested .1 releases.
Grab it yourself if you'd rather not wait. Head here to download the tarball. The SHA256 checksum is 54f889d236d73f497e29f355ad87f03c2bbcde945bb29fbbae2a4b3050e467.
Most people should just wait for their distro to package it. Weston builds with Meson and wants current Wayland and wayland-protocols around it, but that's a tangent if you're only after the i915 fix.
