Hdr fixes

[kode54]

This branch was:

Co-authored-by: Claude Opus 4.7 (1M context) noreply@anthropic.com

---

Some of the changes were hand edits or tweaks, such as the gamma 2.2 change to the add_rect color, which required multiple rewrites before I realized what was up with that:

• The target blend operation is alpha blended with pre-multiplied alpha, so the color that is coming in needs to have its R/G/B divided by the alpha before adjusting it, then scaled by the color multiplier in linear space, then converted back to sRGB, then pre-multiplied by the alpha again. I opted to use gamma 2.2 instead of piecewise sRGB for the space conversions.
• There was a place where the agent decided to try setting a NULL preferred image description, which I discovered is not the legal way to unset the preferred image description. So instead, I opted to write it to set a fallback of sRGB / gamma 2.2, in the case where a "best" format is not found for a surface.
• All the rest of the code did what it was supposed to right out of the generator, so it didn't need any major alterations.
• Except for Uncrustify. I had to fix up a few files with that, and the line breaking comment wrap found a bug in the Uncrustify implementation that needs to run a second pass to check for discontinuity with equals sign spacing. I'll report that on ammen99's uncrustify repository.

[kode54]

Okay, this has an outstanding issue with direct scanout of size mismatched XWayland surfaces, possibly also size mismatched Wayland surfaces, I've committed a fix, will push it once I verify it works correctly.

[ammen99]

In general, I am highly doubtful about some of the latest changes. Why skip the zero-copy path if we don't need HDR / special color transfer functions? Maybe the best solution is something like this:

• Extend get_texture() to also include a parameter saying which color spaces the caller expects
• Make sure get_texture() does not go the zero-copy path if the texture does not match the expected color space
• In the GLES2 codepath, expect SRGB or whatever
• In the Vulkan codepath, say we support all transfer functions.

[ammen99]

is 0 a valid color transfer function? if not, seems like a candidate for std::optional<wlr_color_transfer_function> instead of invalid values.

[ammen99]

Still remains a point for improvement

[kode54]

In general, I am highly doubtful about some of the latest changes. Why skip the zero-copy path if we don't need HDR / special color transfer functions? Maybe the best solution is something like this:

• Extend get_texture() to also include a parameter saying which color spaces the caller expects
• Make sure get_texture() does not go the zero-copy path if the texture does not match the expected color space
• In the GLES2 codepath, expect SRGB or whatever

The altered wlroots code base expects linear in the GLES2 code path as well. And maybe it's worth just getting rid of this branch instead, since I doubt that will ever be merged into wlroots, considering it breaks on Nvidia.

• In the Vulkan codepath, say we support all transfer functions.

[kode54]

It's quite possible I should just discard everything after 2443c5f ... since that's mostly adapting everything to the GLES2 rewrite that will likely never be approved or employed anywhere.

[kode54]

Could you please review again, I'm not sure how much of the above comments are regarding code I decided to move elsewhere for future dealings.

[ammen99]

there are still a few small comments, but overall lgtm. If you fix them and are generally happy with how the PR works on your monitors, we can merge.

[ammen99]

@kode54 I added some more commits to fix the remaining issues, please take a look at my latest changes, test and if it still works ok, I will merge.

[kode54]

Thanks, so much, for looking at this, and for the changes you made to fix my mistake, and also pointing out the really smart use of smart pointers there.

I'll take a look in a few hours, when my evening winds down, and I'll let you know how it worked out.