Apology accepted. 
A little tip: if no one has replied yet, just edit your last post if you want to add new information. Keep it tidy. 
2 Likes
KDE or any DE in matter of fact cant currently take HDR pictures. They will always default into SDR and distort the reality.
But you say the screenshot represent the way how you see the HDR in game.
This could be due to two issues.
Issue 1.
I checked your logs, and for some reason your GPU runs on PCIe gen 2
process: TSMC n7 (7nm) built: 2020-2023 **pcie: gen: 2 speed: 5 GT/s**
My advice:
This should not be, definitely not with the 30XX generation. Please have it fixed.
Issue 2.
There was a funny BUG with NVIDIA (with AMD too but mainly NVIDIA), where when you used a DP cable you had distorted colours.
From the logs I see you use DP connection
active: DP-3
My question here is what kind of cable for DP you use, what is the version standard? (1.4, 14.a or older)? When you want to use high refresh rates and/or HDR you need to have the proper bandwidth.
You monitor supports:
HDMI (v2.0)
DisplayPort (v1.4)
My advice:
A. Try to check what standard generation your current cable uses, if its anything bellow 1.4 it can cause problems.
B. Because of the possibility this is caused by DP, try to use a HDMI connection but once again you need the proper standard generation
4 Likes
Hey! holy smokes why would my card be running in gen 2? that’s a nice catch I never saw. that explains why the sysmon says 100% most of the time when a game is playing while the card is not even breaking a sweat. in the BIOS it’s configured to “AUTO”. I’ll try to set the bandwith manually, hopefully without locking me out of the screen.
The DP cable is the one that came with the monitor. it could very well be a cable with not enough bandwith for HDR, altough to this I can say the following: When first enabling hdr (with the monitor’s 180Hz refresh rate, the change wouldn’t apply. I lowered the refresh rate settings until it did “stick” at 120Hz. It’s strange because, of all things, SDDM does display with incredible color depth, but then the DE doesn’t really change from non-HDR.
For one, I’ll go and change the bandwith from my GPU, the cable theory might take me more time to test, especially since I don’t own more cables right now, and the second monitor’s cables are in a quite uncomfortable position to change.
Thanks for the response!
QUICK UPDATE:
manually altered the connection speed to GEN-5. Gen 4 pcie is now in use, better than nothing to be honest!, will retry the game with hdr and see what happens
UPDATE 2: HDR on wine still looks washed out. Maybe the cable is at fault then?
Yes try the different cables like I mentioned, HDMI cables as well if possible.
Also one more thing you can try, try to set in /etc/environment the following
KWIN_DRM_ALLOW_NVIDIA_COLORSPACE=1
After setting it reboot you PC and test, if nothing changed, remove it and reboot again.
Tried the Env value but it’s still the same.
I’ll try to get a new hdmi cable soon and see if that fixes it!
Sorry, I don’t want to let the thread die, but I still haven’t gotten myself on to getting an hdmi cable, however, I did watch the thread you referenced @Seimus and It’s an apparently fixed bug ¿maybe it’s not a cable thing?
No clue,
But you do not know till you don’t try it.
Anyway, problem with you monitor is I can not even find any reference if and how the HDR works there.
Funny,
So looks like after KDE 6.5 the HDR is broken when using gamescope. KDE did several improvements on the HDR implementation and it bit broke HDR when using gamescope.
Basically when using gamescope for HDR in kwin 6.5. HDR is not working. This is specific only for gamescope as such, the NATIVE wayland driver is not affected.
Xaver already fixed this;
5h ago it was pushed into the git version of gamescope. The ChaoticAUR didn’t yet compile the package, but I believe it will be done soon.
This brings us back to your problem, as with KDE 6.5 HDR got again some improvements. Did you already upgrade to it and test HDR on your monitor using the native driver?
Once the ChaoticAUR has the git package ready for us you can test via gamescope as well.
Its possible that the KDE 6.5 might brought some fixed that would improve on your particular user issue.
4 Likes
As well one very important thing I realised,
Because you are on NVIDIA do you have installed the ‘vk-hdr-layer-kwin6-git’ package?
This is needed because I still think Nvidia didn’t in their drivers implement the Wayland colour management protocol.
Once you have this you can try to run a game with
Proton-ge setting the launch option
PROTON_ENABLE_WAYLAND=1 PROTON_ENABLE_HDR=1 ENABLE_HDR_WSI=1 %command%
Gamescope setting the launch option try one of these
DXVK_HDR=1 ENABLE_HDR_WSI=0 gamescope -w 2560 -h 1440 -f -r 120 --hdr-enabled -- %command%
ENABLE_HDR_WSI=0 gamescope -w 2560 -h 1440 -f -r 120 --hdr-enabled -- %command%
gamescope -w 2560 -h 1440 -f -r 120 --hdr-enabled -- %command%
3 Likes
ok, now this sounds like it could be the problem
I don’t have that variable set, which means that even kde isn’t properly rendering hdr color, am I correct? the arch wiki does state it’s not recommended to be set globally though
If kde hdr works I’d definitely rather use that implementation, as creating a smaller gamescope window was always cumbersome.
As far as the update, i’m seeing the same as I said before, the colors are slightly washed-out compared to hdr being off. haven’t tested a game yet so I will report back when I do!
As for the package
I checked, I do have it installed, however I reinstalled it to be sure.
Basically it enables the Vulkan layer, which is off by default for NVIDIA and AMD (prior MESA 25.X). Where MESA advanced very fast and intergraded the Wayland colour management protocol. NVIDIA is behind and needs to use the mid-layer from the package and the environment variable to communicate in HDR properly.
Do not set it globally, cause for NVIDIA it caused black screen during bootup. Set it per game in the launch options. Basically try the commands I provided above.
1 Like
3.16.17.r20.g7d4e835-1 already on ChaoticAur. I tested it and its working 
3 Likes
I think the correct model “name” (which is not the one the OSD tells is the following:
ViewSonic VX3218C
It’s a little late, but I’ll ammend my first post too so it reflects that
Edit:
I’ve looked at the KDE forum and this discussion:
If I am understanding correctly, it’s either SDR displaying correctly, or HDR displaying correctly, as they are somewhat conflicting standards?
can anyone confirm this? if that’s it then there’s nothing to be done by either garuda or kde, as it’s just a bad standard
Didn’t fully read through the whole topic, but the discussion they are having around the post you mentioned is about HDR and Videos/Movies.
Its not a bad standard. The standard that was chosen for HDR on Linux gives perfect sense.
When speaking about SDR and HDR, those are not conflicting standards. Those are standards for SDR and HDR. Where SDR can not represent HDR but HDR can represent SDR.
In case you run HDR, but you view on it a SDR standard, HDR needs to properly represent it. For this we have the calib tools and sliders, to tune it.
HDR on Linux works, and it can properly represent SDR as well. I have always on HDR that is calibrated via KDE, and SDR content tuned via sliders, as described in the Wiki.
My calibration is done in such a way that if I disable HDR, the brightness of SDR contend in HDR perfectly matches the brightness of native SDR output.
3 Likes