pipewire: Add support for SPA_VIDEO_FORMAT_xBGR_210LE video streams

[flibitijibibo]

This is pulled from @IceDBorn's local work to support headless HDR streaming; the full patchset for that can be found here:

https://github.com/IceDOS/apps/blob/main/modules/steam/modules/sunshine-headless-session/lib/

While this appears to work with the above patches in headless mode, this is marked as a draft since I haven't been able to test this with the DRM backend (see #2126), and we didn't want to break Steam Machines by accident.

[IceDBorn]

Precisely, this has only been tested by me and some of my friends, on our TVs - headless only. I'm not even sure if the HDR signal is correct, it just looks ok to me.

[luxus]

Looks good for pipewire.cpp. A few notes on pairing with paint_pipewire so remote HDR color stays correct.

[luxus]

Offering xBGR_210LE when HDR is on is correct.

Still needed in paint_pipewire (not in this PR):

frameInfo.outputEncodingEOTF = g_bOutputHDREnabled ? EOTF_PQ : EOTF_Gamma22;

Today it stays EOTF_Gamma22 while we advertise BT.2020/PQ here → washed hybrid streams on remote clients.

[flibitijibibo]

Looking at paint_pipewire it looks like we may also need to apply similar logic to the color management as well, does this make sense?

diff --git a/src/steamcompmgr.cpp b/src/steamcompmgr.cpp
index 9b32e2b..74240bd 100644
--- a/src/steamcompmgr.cpp
+++ b/src/steamcompmgr.cpp
@@ -2337,15 +2337,16 @@ static void paint_pipewire()
 
        struct FrameInfo_t frameInfo = {};
        frameInfo.applyOutputColorMgmt = true;
-       frameInfo.outputEncodingEOTF   = EOTF_Gamma22;
+       frameInfo.outputEncodingEOTF   = g_bOutputHDREnabled ? EOTF_PQ : EOTF_Gamma22;
        frameInfo.allowVRR             = false;
        frameInfo.bFadingOut           = false;
 
        // Apply screenshot-style color management.
+       auto& luts = g_bOutputHDREnabled ? g_ScreenshotColorMgmtLutsHDR : g_ScreenshotColorMgmtLuts;
        for ( uint32_t nInputEOTF = 0; nInputEOTF < EOTF_Count; nInputEOTF++ )
        {
-               frameInfo.lut3D[nInputEOTF]     = g_ScreenshotColorMgmtLuts[nInputEOTF].vk_lut3d;
-               frameInfo.shaperLut[nInputEOTF] = g_ScreenshotColorMgmtLuts[nInputEOTF].vk_lut1d;
+               frameInfo.lut3D[nInputEOTF]     = luts[nInputEOTF].vk_lut3d;
+               frameInfo.shaperLut[nInputEOTF] = luts[nInputEOTF].vk_lut1d;
        }
 
        const uint64_t ulFocusAppId = s_pPipewireBuffer->gamescope_info.focus_appid;

[luxus]

Yes — that paint_path change makes sense, and it belongs with this PR (or as a tight companion).

Why: this PR offers xBGR_210LE with BT.2020 + SMPTE2084 when HDR is on, but paint_pipewire still hardcodes EOTF_Gamma22 and the SDR screenshot LUTs. That mismatches metadata vs what is actually written into the PW buffers (hybrid: PQ-tagged stream, gamma/SDR paint) and washes out or skews colors on remote capture clients.

What needs to stay locked together:

1. Format offer + colorimetry for xBGR_210LE (this PR)
2. frameInfo.outputEncodingEOTF = g_bOutputHDREnabled ? EOTF_PQ : EOTF_Gamma22
3. HDR vs SDR screenshot LUT sets: g_ScreenshotColorMgmtLutsHDR when HDR is on, g_ScreenshotColorMgmtLuts when not

Your diff covers (2) and (3) cleanly. Without them, mid-session HDR renegotiation to 10-bit is incomplete for PipeWire consumers.

(We've been shipping that paint companion next to a cherry-pick of this PR on a gamescope fork used for headless streaming; drop it when this lands upstream.)

[flibitijibibo]

Well, that covers what the robots think... anyone on payroll have any thoughts?

[luxus]

the user of the robot can confirm that it works :D
the reason i let my clanker wrote the post.. i want to confirm that this pr is working on 3-5 devices