Wayland Protocols 1.49 Closes Multi-GPU, HDR, and Scaling Gaps

Wayland Protocols 1.49, published June 7 by Simon Ser, the project’s lead maintainer, ships three protocol additions: improved multi-GPU buffer feedback through linux-dmabuf-v1, Windows BT.2100 image description support in color-management-v1, and an experimental fractional-scaling upgrade labeled xx-fractional-scale-v2. All three carry one author, KDE developer Xaver Hugl, who has been pushing these changes through the upstream review process since at least 2022.

What Wayland Protocols 1.49 Delivers

The Wayland Protocols repository holds the canonical set of extension protocols that compositors and applications implement to negotiate display capabilities. Each numbered release collects changes that have cleared the project’s consensus process. Simon Ser, also known online as emersion, publishes each release once contributions have passed review; compositors, toolkits, and individual applications then implement the new protocol objects on their own schedules.

Version 1.49 is small by commit count. The three additions touch areas of the stack in active use across major compositors.

• linux-dmabuf-v1 multi-GPU additions: compositors can now advertise which devices they support and which pixel formats and modifiers they can import from each, giving clients rendering on a non-primary GPU the information they need before allocating buffers
• color-management-v1 BT.2100 image description: a new request for Windows-scRGB encoding lets compositors handle the HDR color signal Windows uses internally when driving a display in BT.2100/PQ mode
• xx-fractional-scale-v2 (experimental): a coordinate system that communicates surface positions in unscaled physical pixels, addressing the rounding errors the current integer-based logical space cannot avoid at non-integer scale factors

The Multi-GPU Buffer Blind Spot

What the Client Couldn’t Know

On a system with both an integrated GPU and a discrete graphics card, Wayland clients rendering on the secondary device face a specific problem. The linux-dmabuf-v1 protocol reference covers how clients transfer rendered frames to the compositor using the kernel’s DMA-BUF (Direct Memory Access Buffer) mechanism: buffers move from GPU memory to GPU memory without copying through the CPU. It has been a stable part of the Wayland stack for years.

The gap was this: if a client allocates a buffer on device A and the compositor’s primary device is B, the compositor attempts to import that buffer. If the import fails because of a format mismatch, an unsupported modifier, or incompatible memory placement, the client receives nothing back. No error event, no alternative path to try, no indication that the frames it submitted were unusable. Xaver Hugl started pushing a fix through the upstream protocol process in 2023; the KDE KWin multi-GPU issue tracker shows this as an open problem since at least 2021.

Gaming laptops with a discrete GPU alongside an integrated chip, and eGPU setups, are the most common configurations where clients render on a different device than the compositor’s primary. On these systems, buffer mismatches were silent: no error raised, just frames the compositor couldn’t import.

What Compositors Signal Now

The 1.49 additions give compositors a protocol-level mechanism to describe their actual capabilities per device. A compositor can now explicitly advertise each device on the system and, for each one, list the pixel formats and modifiers it can successfully import. Clients query this before allocating, choosing a format and device pairing the compositor has confirmed it supports.

The protocol also allows per-surface granularity. When a surface is being scanned out on a different GPU than the compositor’s compositing engine, the compositor can signal a different preferred device for that surface specifically. That level of granularity matches how real multi-GPU hardware behaves: different outputs often attach to different cards, and the optimal buffer path for a given surface depends on where that surface is actually displayed.

The underlying hardware handled cross-GPU rendering in most configurations. The protocol lacked any formal mechanism for compositors to communicate what they could actually import from each device.

Windows HDR Content in Wayland’s Color Stack

The color-management-v1 protocol has been on an accelerated adoption path since it merged upstream in February 2025, after roughly five years in design. KWin, Mutter, and the wlroots library all have implementations. Firefox has experimental Wayland HDR support since version 138, enabled via the gfx.wayland.hdr flag. Chromium merged native Wayland HDR color management in version 141. Both use color-management-v1.

What 1.49 adds to this developing protocol is a specific image description request for “Windows-scRGB” encoding. This is the color encoding Windows uses internally when driving a display in BT.2100/PQ (Perceptual Quantizer) signaling mode; BT.2100 is the ITU-R standard for HDR television content, specifying a target peak display luminance of at least 1,000 cd/m². The color-management-v1 protocol specification defines Windows-scRGB as a pre-defined image description compositors can match against incoming surface color descriptions.

• Color primaries: sRGB (BT.709), not the wide-gamut BT.2020 primaries BT.2100 displays typically use
• Transfer function: extended linear, with channel values ranging below 0.0 and above 1.0
• Negative values: represent colors outside the sRGB gamut boundary
• Required pixel format: 16-bit floating point, to carry the extended channel range

For a Wayland compositor, the practical use is recognizing this encoding when a Windows-native application via Wine or Proton outputs HDR content, or when a media player signals Windows-scRGB as its surface color description. X.org has no plans to support HDR. All HDR paths on Linux go through Wayland compositors.

Fractional Scaling Gets a Second Coordinate System

The wp-fractional-scale-v1 protocol, stable since 2022, tells clients what scale factor to apply to their surfaces. Clients render at that scale and submit the resulting buffer. The problem sits a layer lower: the coordinate space that clients and compositors use to describe surface positions relies on integer-based logical pixels, and at scale factors like 125% or 150%, the rounding produces one-pixel seams between maximized windows and panels on high-DPI displays. KDE’s KWin merge request for the new protocol documents this with video recordings of both behaviors.

The xx-fractional-scale-v2 protocol changes the coordinate unit to unscaled physical pixels. Clients and compositors negotiate positions in actual device pixels rather than a logical approximation, which eliminates the rounding at boundaries between adjacent surfaces. The “xx” prefix signals experimental status in Wayland protocol naming: the protocol is available for compositor implementation now, but backward-incompatible revisions remain possible as compositors encounter edge cases.

Xaver Hugl’s original proposal for this approach dates to 2022, circulating first as “wp-fractional-scale-v2” before a rename on entry avoided a naming collision with the v1 work. KDE’s Vlad Zahorodnii authored the KWin-side implementation. KDE Plasma 6.7, scheduled for release this month, ships with it.

Three Years from Proposal to Protocol

The Consensus Bottleneck

Wayland protocol development requires consensus across compositor teams. A proposal doesn’t land until maintainers across KWin, Mutter, wlroots, and other compositors agree the design is workable for each of their implementations. Xaver Hugl has been navigating that process across three separate protocol domains at the same time.

The fractional scaling work is the oldest: a 2022 proposal that went through a name change and an extended review cycle before landing. The DMA-BUF multi-GPU additions started in 2023. Both had compositor-side work underway before the formal upstream inclusion in 1.49.

Compositor Adoption from Here

Simon Ser’s Wayland Protocols 1.49 release announcement on the wayland-devel mailing list carries the full change list. The mailing list is where compositor maintainers track releases before distribution packages catch up.

For Sway and other compositors built on wlroots, which already support color-management-v1, the BT.2100 image description request is a separate addition that requires its own implementation work. For the linux-dmabuf-v1 additions, compositors must implement per-device format and modifier advertising alongside per-surface capability signaling, two new protocol objects that weren’t part of the prior version.

KDE Plasma 6.7 ships xx-fractional-scale-v2 support when it releases this month. The linux-dmabuf-v1 multi-GPU additions and the BT.2100 color management request are in the 1.49 release; compositor adoption is what carries them to the desktop.