@UjinT34

Current tonemapping is also inspired by kwin. If they changed theirs then we should probably do the same. Might be harder to track every necessary change because they combine cpu calcs, shaders and drm properties.
Tonemapping happens when source max luminance is higher than the target one. Most games set their luminance to 10000 or some other high value which almost always results in HDR -> HDR tonemapping. So this PR will affect desktop HDR and fullscreen HDR with cm_fs_passthrough = 0. Might make it better or worse but most likely it'll be too subtle to notice.

@UjinT34 Thanks, I didn't consider that.
Do you think it warrants a check for HDR-on-HDR to bail, and maybe a new config var for that?

My HDR displays are all Mini-LED, so I can't be sure how it'll look on e.g. OLEDs with HDR400.

tonemap works with linear values and shouldn't care about SDR/HDR. I don't think we need a separate codepath for that unless someone has issues with HDR and new tonemapping.

Rebased and moved to a more general HDR-to-SDR check to use transfer function luminances for tonemapping across the board.

This change makes the improved tonemapping apply to HDR content on SDR displays too, instead of just in screenshare.

If Auto-HDR might cause apps to always output HDR, this should make things look okay when you're un-fullscreened and back to SDR.

Updated to fix a slight blue-green hue I noticed for HDR->SDR.

@UjinT34 I've been using this with #12127 on my system for a while, and everything seems to work as intended.

Any changes you'd like to see to get them merged?

lgtm

@vaxerski ?