I guess unset_image_description is valid for sRGB surfaces. In which case creating an sRGB image description is unnecessary.

All that's actually needed is to avoid preemptively creating image descriptors that are unsupported by the compositor, and throwing an error when transitioning to one.

CI is broken?

Thank you. On the latest version of this PR, colors look correct again + HDR works on Gnome now.

Were the colours off on my first attempt? 😅

At least on Hyprland, yeah they had a weird hue xD (no HDR)

We should probably make something smarter here and reject Presents with unsupported output TFs and manually output HDR10/whatever is supported.

One thing I don't understand is, why is this not needed with wine wayland? Does wine internally convert everything to bt.2020 container? What's an example of a game/something that uses scRGB? I must say, that wine wayland now works great under gnome and the last hurdle is that steam input just doesn't work at all with wayland driver :/

Heya, I'm assuming the checks failing is still a problem, I did some digging and seems that the arch repos recently changed the wlroots package name to have multiple versions available. It's probs causing issues on your build but not others yet as it is a fresh system/build-pipeline.

I don't really know much about github build stuff, just guessing why tests after yours haven't failed yet, but this is likely going to cause problems for future PRs that use the current build workflow file.

Dunno if this warrants making a new issue or such to specifically address the workflow file now being outdated. Should hopefully be an easy fix of changing wlroots to wlroots0.19, wlroots0.18 or wlroots0.17 depending on whichever is preferred in the workflow file for future builds.

Re: Switch to a versioned packaging scheme for wlroots :

On 5/28/25 10:03 AM
The wlroots0.19 [1] and wlroots0.18 [2] packages (plus the related 
rebuild [3]) have now entered [extra].
The "regular" wlroots package has been dropped from the repo (users will 
be automatically prompted to make the switch to the wlroots0.18 package 
at their next system upgrade).
Thank you all!

The CI failure has already been addressed with #1877

As for apps/games that use scRGB, off the top of my head Control's HDR implementation uses that colorspace.

How do you re-run the failed check now that the CI has been fixed upstream? As this fixes an issue that essentially breaks gamescope on gnome (sdl backend only fixes AMD systems, and also can cause performance issues for some), and a good chunk of users don't want to compile the fixed version themselves, it would be good if we tried to merge it again so distro repos can roll it out sooner for less technical users.

Sorry for for not staying on top of this.

We should probably make something smarter here and reject Presents with unsupported output TFs and manually output HDR10/whatever is supported.

Could you elaborate on this? I'm trying to figure out whether this is a big or trivial change 😅.
Would that require shaders to map colour spaces to the ones that are available? Or do you mean fallback to using the HDR10 code path to display scRGB buffers?

Maybe construct a description based on the values set in the kwin implementation 🤷:
https://invent.kde.org/plasma/kwin/-/blob/master/src/wayland/colormanagement_v1.cpp#L94-107

Responding to: #1867 (comment)

Nah, it's all good, we all have lives and such heh. Just thanks for helping fix these kinda things! 💜

TransferFunction(TransferFunction::linear, 0, 80),

Implys that it sets min and max luminance to 0 and 80.
And the reference luminance is set to 203 which is a little confusing.
The spec says something about the maximum being 10k cm^-2.

Previously on this branch m_pWPImageDescriptions[ GAMESCOPE_APP_TEXTURE_COLORSPACE_SCRGB ] would never be set as I was checking the feature compatibility before the relevant events were received. However I can't see where this variable is used so it probably didn't cause an issue.

I haven't been able to trigger scRGB on gamescope yet. The Cyberpunk 2077 does seem to change it's rendering in scRGB mode (it looks off) but gamescope seems to stick with PQ.

I've gotten gamescope to output in scRGB with Control by using kwin.

Looking at the output of vulkaninfo on my hardware, mutter seems to not support R16G16B16A16_UNORM which appears to be the format used by gamescope for color management LUTs.

I'm trying to figure out what the likelihood of an app trying to present an scRGB surface where the compositor doesn't have windows_scrgb support is.

I feel that not crashing on every compositor but kwin is worth the risk of some app / compositor combination displaying in the wrong colorspace. That bug can be investigated once it exhibits.

That is to say: Would you merge this if I revert this branch to print a warning and unset the image description of the surface when gamescope is attempting to display an scRGB image on a compositor that doesn't support the windows_scrgb feature?

I've updated this branch to be very simple.
It moves the problematic calls out of the wl_registry::global callback, makes them dependant on the color management compatibility check, and adds a check for the windows_scrgb feature to said checks.

Any chance of getting this merged?
It is a very simple change.

Perhaps bringing to the attention of @kisak-valve would help if it's fallen through the cracks.