HDR no longer works with Sway

[njdom24]

Is there an existing issue for this?

• I have searched the existing issues

Are you using any gamescope patches or a forked version of gamescope?

• The issue occurs on upstream gamescope without any modifications

Current Behavior

The changes introduced in #1999 stop Sway from getting an HDR output from Gamescope. I think the checks in SupportsColorManagement() are too restrictive.

Steps To Reproduce

1. Run sway-git, swaymsg output DP-1 hdr on
2. Launch app with Gamescope
3. Sway gets HDR image tonemapped to SDR instead of HDR output

Hardware information

- Distro: NixOS 25.11 (Xantusia)
- CPU: AMD Ryzen 7 9700X
- GPU: AMD Radeon RX 9070 XT
- Driver Version:

Software information

- Desktop environment: `sway version 1.12-dev`
- Session type: Wayland
- Gamescope version: gamescope version 7d4e835a25cc85017380cbd743d517b48932fb75 (gcc 14.3.0)
- Gamescope launch command(s): `gamescope --hdr-enabled --hdr-debug-force-support -- vkcube`

Which gamescope backends have the issue you are reporting?

• Wayland (default for nested gamescope)
• DRM (default for embedded gamescope, i.e. gamescope-session)
• SDL
• OpenVR

Logging, screenshots, or anything else

[gamescope] [Info]  xdg_backend: HDR INFO
[gamescope] [Info]  xdg_backend:   cv_hdr_enabled: true
[gamescope] [Info]  xdg_backend:   uMaxLum: 10000, uRefLum: 203
[gamescope] [Info]  xdg_backend:   bExposeHDRSupport: false

[misyltoad]

@Zamundaaa

[Zamundaaa]

Please run gamescope with WAYLAND_DEBUG=1 and attach the output here. I have the suspicion that Sway doesn't send the target luminance event.

--hdr-debug-force-support

We should probably make this work either way though

[njdom24]

Captured with WAYLAND_DEBUG=1 WLR_RENDERER=vulkan sway and WAYLAND_DEBUG=0 gamescope:

sway_hdr_standalone.log

And another log with WAYLAND_DEBUG=1 exported to both:

sway_hdr.log

[njdom24]

I'm just patching this for now. I assume it'll be a non-issue by the time Sway makes a stable release with CM enabled. It's generally buggy at the moment anyway.

diff --git a/src/Backends/WaylandBackend.cpp b/src/Backends/WaylandBackend.cpp
index ab6d30c..412bf45 100644
--- a/src/Backends/WaylandBackend.cpp
+++ b/src/Backends/WaylandBackend.cpp
@@ -2384,7 +2384,8 @@ namespace gamescope
 
     bool CWaylandBackend::SupportsColorManagement() const
     {
-        return m_pFrogColorMgmtFactory != nullptr || ( m_pWPColorManager != nullptr && m_WPColorManagerFeatures.bSupportsGamescopeColorManagement );
+        
+        return m_pFrogColorMgmtFactory != nullptr || ( m_pWPColorManager != nullptr && m_WPColorManagerFeatures.bSupportsGamescopeColorManagement ) || g_bForceHDRSupportDebug;
     }
 
     void CWaylandBackend::SetCursorImage( std::shared_ptr<INestedHints::CursorInfo> info )

[Zamundaaa]

Sway only supports feature_parametric and feature_set_mastering_display_primaries, but gamescope needs feature_windows_scrgb for scRGB games (or with some changes at least feature_extended_target_volume).

The requirement on feature_set_luminances could perhaps be relaxed, but as is, I don't think exposing support for scRGB would be a good idea on Sway. If you do a few more changes to split up support for PQ and scRGB into two separate features, that could make it almost work...

The other problem is that Sway's preferred image descriptions for the surface and for outputs are all plain sRGB, there's no HDR to be seen in your log.

[  75005.948]  -> wp_image_description_info_v1#57.luminances(2000, 80, 80)
[  75005.952]  -> wp_image_description_info_v1#57.target_primaries(640000, 330000, 300000, 600000, 150000, 60000, 312700, 329000)
[  75005.958]  -> wp_image_description_info_v1#57.target_luminance(2000, 80)