HDR outputs are always captured as sRGB, even for colour-management-aware screencopy clients

[Jhonfel]

Hi! I've been trying to stream an HDR desktop from Hyprland with Sunshine (to Moonlight on a Mac), using a headless output as the stream target. I got it working in the end, but only after patching Hyprland in a few places, so I wanted to share what I found and ask how you'd prefer this to be handled before I open a PR.

Setup

• Hyprland 0.56.2, built from source (Arch's PKGBUILD + my patch below). I also checked main and the relevant code is unchanged; line numbers below are from main.
• NVIDIA RTX 5090, open kernel module 615.71.09, kernel 7.2.7.
• The capture client is Sunshine built with LizardByte/Sunshine#5615, which binds wp_color_manager_v1 and reads the captured output's image description over wlr-screencopy. If the output is BT.2020 + PQ, it sends HDR10 to the client.
• The output is a headless one (hyprctl output create headless), switched to HDR with a monitorv2 block (supports_hdr = 1, bitdepth = 10, cm = hdr, plus explicit luminances since there's no EDID).

Steps to reproduce

1. Put any output in cm = hdr, bitdepth = 10.
2. Capture it with a screencopy client that binds wp_color_manager_v1 and treats the frame according to the output's image description (patched Sunshine above; any CM-aware client should show the same thing).
3. Look at the result on an HDR display.

Expected: the client gets the frame in the output's own colour space (PQ / BT.2020), since it asked about it through the colour-management protocol and was told the output is HDR.

Observed: the client gets sRGB-encoded pixels. Because the output advertises PQ, the client decodes them as PQ: everything is far too bright and oversaturated, and warm whites shift towards red. A non-CM-aware client like grim gets plain sRGB (whites at 255), which is fine for it.

What I found

There are three places where the capture ends up in sRGB no matter what the client supports:

1. src/managers/screenshare/ScreenshareFrame.cpp: copyDmabuf() (L405) and copyShm() (L446) always set the target framebuffer's image description to DEFAULT_SRGB_IMAGE_DESCRIPTION. renderMonitor() already computes IS_CM_AWARE and passes cmBackToSRGB = !IS_CM_AWARE, but because the target FB description is set explicitly, renderTexture uses it (OpenGL.cpp, TARGET_IMAGE_DESCRIPTION), and the frame gets converted to sRGB anyway.
2. src/output/MonitorResources.cpp: getMirrorTexImageDescription() (L202–207) returns DEFAULT_SRGB_IMAGE_DESCRIPTION for anything that isn't sRGB/gamma 2.2, so the capture mirror of a PQ output is already SDR before the screenshare code runs.
3. src/output/Monitor.cpp: needsUnmodifiedCopy() (L2659) returns true for a PQ output with non-default SDR settings whenever a copy FB is needed, even with render:keep_unmodified_copy = 0. The unmodified copy is written by doColorManagement() in cm_helpers.glsl with the sRGB transfer function and SDR_MAX_LUMINANCE (80 nits). So a capture client never sees sdr_max_luminance / sdrbrightness, and SDR content inside HDR looks very dull.

On top of that, two defaults got in the way:

• misc:screencopy_force_8b defaults to true, so the capture of a 10-bit output is 8-bit.
• With render:use_fp16 = 2 (auto), a PQ output is composed in a linear FP16 work buffer. When the capture mirror is filled from it (saveBufferForMirror), the result is washed out with bluish blacks; the linear→PQ conversion there doesn't seem to scale the same way the final output pass does (doColorManagement skips toNit() for a linear source). With use_fp16 = 0 the work buffer is PQ and the copy is exact.

What I did

I added an opt-in misc:screencopy_hdr_passthrough (default false), which:

• makes getMirrorTexImageDescription() return the output's own description;
• uses the output's description as the capture target in copyDmabuf()/copyShm() when the client is CM-aware (isClientCMAware); others still get sRGB, as now;
• makes needsUnmodifiedCopy() return false, so the capture sees the frame as displayed, SDR adjustments included.

Patch (against 0.56.2, +36/−5): https://github.com/Jhonfel/sunshine-hyprland-virtual-display/blob/feat/client-resolution/patches/hyprland-0.56.2-screencopy-hdr-passthrough.patch

With this, screencopy_force_8b = false and use_fp16 = 0, I get correct HDR10 end to end. Colours match, blacks are black, and the desktop brightness follows sdr_max_luminance.

Questions

• Would you rather this be the default for CM-aware clients instead of an option? A client that binds wp_color_manager_v1 and queries the output presumably expects the output's colour space, but wlr-screencopy itself has no way to say which description the buffer is in, so I kept it opt-in to be safe.
• The FP16 part is probably a separate bug: the capture copy from the linear work buffer comes out wrong. I haven't looked at a proper fix, only worked around it.
• If you're OK with the approach, I'm happy to rebase it on main and open a PR.

Related: #13831 (the opposite direction, HDR→SDR for non-CM-aware clients), #14931 and #10953 (screenshots and screenshare with HDR).

Thanks for all the work on colour management, by the way. Most of the pieces were already there.

[github-actions[bot]]

This discussion has been automatically closed.
Discussion format is NOT optional!

[github-actions[bot]]

⚠️ Strike 1/3 issued to @Jhonfel by system.