Color management features - #1
Merged
dividebysandwich merged 20 commits intoJul 9, 2026
Merged
Conversation
This makes it possible for multiple `Dmabuf`s, or multiple planes of one `Dmabuf`, to share an fd without having to `dup`.
It seems this was ultimately ignoring the `plane_idx` and ordering based on the order of calls? Presumably that is not correct.
These functions now return `OwnedFd`, so the type already implies what this comment says. There is not an unsafe call here.
Planes being added out of order seems to just be a quirk of the linux-dmabuf-v1 protocol, so we can handle sorting there.
`zwp_linux_buffer_params_v1` specifies that planes should start at 0 and be consecutive (but can be added out of order). Add a check for this, and send a protocol error if it fails.
This workaround is no longer needed if we `Arc` the FD.
Adds ConnectorColorState (Colorspace, HDR_OUTPUT_METADATA, max bpc) as part of the atomic surface's pending state, staged via DrmSurface::use_color_state and applied together with mode, CRTC and plane state in a single atomic commit. Support is probed via supported_colorspaces, hdr_metadata_supported and max_bpc_range; DrmCompositor gains thin delegations. Color properties are never emitted on page flips (the kernel latches them), and reset_connector now restores default SDR signalling so the next KMS client starts from a defined state. The current connector color state is read back on surface creation and resume, so foreign HDR signalling is detected and reset on the next commit. Committing these properties standalone (without full pipeline state) hangs the display pipe on some drivers, notably nvidia — staging them into the one atomic commit is the reliable path, mirroring what aquamarine/Hyprland does. Co-authored-by: Victoria Brekenfeld <github@drakulix.de>
Implements the stabilized wp-color-management-v1 (staging) and the color-representation protocols: parametric image descriptions, surface description feedback with change notifications, and color representation (alpha mode, chroma location, coefficients). Dispatch is provided through the crate-wide delegate_dispatch2! model via per-resource Dispatch2/GlobalDispatch2 impls. Co-authored-by: Victoria Brekenfeld <github@drakulix.de>
Adds a renderer-level default texture-program override (GlesRenderer::set_default_tex_program_override) and a solid-color transform hook (GlesRenderer::set_solid_color_transform), with matching per-frame controls on GlesFrame, so compositors can apply color/tone mapping during composition (e.g. compositing SDR content into an HDR blend space). Co-authored-by: Victoria Brekenfeld <github@drakulix.de>
Store mastering display primaries (previously accepted but discarded) in ImageDescription and allow compositors to advertise Feature::ExtendedTargetVolume; SetMasteringDisplayPrimaries is force-added alongside it, as the protocol only permits the former with the latter. Without the feature, image descriptions whose target color volume exceeds the primary color volume (mastering primaries outside the container gamut, or reference white above max luminance) now fail gracefully with cause "unsupported", as the protocol recommends; failed descriptions never become ready and are rejected in set_image_description and get_information. Adds a public Chromaticities type with the H.273 table for all named primaries and an exact-integer gamut containment test, used both for the validation and to emit the previously missing primaries and target_primaries info events. Also fixes conformance gaps in the same area: set_mastering_luminance is now gated on the set_mastering_display_primaries feature, and the spec-mandated already_set and invalid_luminance checks (including max_fall <= max_cll at create) are enforced.
Implement create_windows_scrgb when the compositor advertises Feature::WindowsScrgb, previously rejected unconditionally. The resulting description mirrors KWin's construction: sRGB primaries and white point, extended-linear transfer with 1.0 = 80 cd/m², an assumed 203 cd/m² (BT.2408) reference white and an assumed BT.2020 target volume. Per the protocol, get_information is rejected on it with no_information. The description carries an explicit windows_scrgb flag (also part of its identity, so it never deduplicates against a parametric twin with identical values). A future tone mapping implementation must treat flagged content as display-referred and pass it through unmapped (clamping at most), unlike client-authored parametric descriptions using the same extended-linear transfer. KWin only distinguishes this case implicitly through luminance metadata; the explicit flag keeps the exemption durable. is_hdr() now also reports true for scRGB. Chromaticities::from_named is const now so the scRGB constant can embed the assumed BT.2020 target primaries.
Implement the set_primaries request when the compositor advertises Feature::SetPrimaries, previously rejected unconditionally. ImageDescription's primaries field becomes a PrimariesOption carrying either named primaries or raw CIE 1931 xy chromaticities; the setters enforce mutual exclusion via already_set, and create requires exactly one of the two. The info events send primaries_named only when the description was built from named primaries, while the primaries coordinates and the target-primaries fallback resolve through the new Chromaticities::from_option. The extended-target-volume containment check now validates mastering primaries against custom container gamuts too. is_hdr() keeps keying wide-gamut detection off named BT.2020 only.
The protocol requires the image description info object to send the luminances and target_luminance events for parametric descriptions; previously luminances was never sent and target_luminance only when the client had provided a mastering luminance. Clients key real behavior off these values: winewayland only reports an HDR display to Windows when the output description's max target luminance exceeds its reference white, so with both events missing HDR detection always failed. luminances falls back to the transfer function's implied defaults from the spec (PQ 0.005/10,000/203, HLG 0.005/1,000/203, BT.1886 0.01/100/100, otherwise the sRGB 0.2/80/80), exposed as ImageDescription::luminances_or_default for compositors. target_luminance falls back to the primary color volume range, per the set_mastering_luminance description.
Bump the wp_color_manager_v1 global from version 1 to 3 and implement create_windows_bt2100 when the compositor advertises Feature::WindowsBt2100. The description is PQ/BT.2020 with the protocol-suggested 203 cd/m² reference white, carries a windows_bt2100 flag like the scRGB one (distinct identity, exempt from tone mapping, no get_information), and composites like regular PQ content. winewayland maps VK_COLOR_SPACE_HDR10_ST2084_EXT swapchains exclusively through this request, so HDR10-native games need it. Version handling: enum entries deprecated in or newer than the bound version are filtered when advertising (srgb/ext_srgb TFs hidden from v2+ clients and rejected in set_tf_named, compound_power_2_4 and absolute_no_adaptation hidden from v1, windows_bt2100 hidden below v3); v2+ objects get ready2/preferred_changed2 with 64-bit identities instead of the deprecated 32-bit events (identities were already never recycled); the v2 get_image_description request fails gracefully since this implementation never hands out image description references.
Parametric image descriptions with the ext_linear transfer function carry extended-range (scRGB-style) content: Mesa's Wayland WSI creates exactly such descriptions for VK_COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT swapchains. Include the transfer function in is_hdr() so compositors keying HDR engagement off it (e.g. fullscreen passthrough) cover native extended-linear clients, not just the pre-defined Windows-scRGB description.
dividebysandwich
merged commit Jul 9, 2026
a75110d
into
dividebysandwich:master
2 of 4 checks passed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.