KDE Making Good Progress On HDR, Better Gamescope Integration

[pesekcuy]

Desktop with AMD APU (Ryzen 9 5900HX).

5900HX was intended for laptops, although some were flocking into mini PCs

[Berniyh]

Unless you have a reason to *not* set them globally, there is no need to not put them in /etc/environment.

You're being ridiculous...

[Quackdoc]

You're being ridiculous...

feel free to share.

[NeoMorpheus]

When I tried HDR with NVIDIA's deepcolor mode it produced washed out colours and overexposed whites. I hope this can be improved, I don't know where the blame falls tho.

Really? Of course its fucking Ngreedias fault. But nooo, we cant point a finger towards a FOSS hostile corporation because we keep bending over to it.

[theriddick]

I wouldn't call them hostile. Certainly their coming around lately.

[bple2137]

Granted, gamescope as a middlemen is not perfect, so the next time I check the progress is when it's not necessary to run it

That will probably take a while. It won’t happen until winewayland.drv implements it and it runs by default in Wine and Proton, so probably at least about 2-3 years from now. For native games this is already possible

EDIT: according to this https://github.com/Zamundaaa/VK_hdr_...h-wine-wayland the experimental Wine driver does implement the WSI layer for HDR. If I understand correctly, this allows for skipping gamescope

[Vistaus]

5900HX was intended for laptops, although some were flocking into mini PCs

Be that as it may, my point is that HDR over DP doesn't work for me and that point still stands. The fact that I have a mini PC with a CPU that was intended for laptops doesn't change anything about the situation.

[skeevy420]

feel free to share.

Multi-user systems where not everyone or every account needs an experimental feature enabled, machines that don't have SU permissions to access /etc/environment or /etc/environment.d/*.conf, some immutable root setups, and other niche setups. For single user or multi-user gaming gaming and desktop rigs, I agree, there's next to no reason not to use /etc/environment outside of trying to be in the habit of doing things without root, without polluting root, or on a per-user basis; my reasons for preferring the ~/.config/environment.d/*.conf way.

[Quackdoc]

Multi-user systems where not everyone or every account needs an experimental feature enabled, machines that don't have SU permissions to access /etc/environment or /etc/environment.d/*.conf, some immutable root setups, and other niche setups. For single user or multi-user gaming gaming and desktop rigs, I agree, there's next to no reason not to use /etc/environment outside of trying to be in the habit of doing things without root, without polluting root, or on a per-user basis; my reasons for preferring the ~/.config/environment.d/*.conf way.

that would explicitly be the situation I mentioned,

> Unless you have a reason to *not* set them globally, there is no need to not put them in /etc/environment.

but even then, how different are a lot of these systems, on a multi user system, most will still be using the same DE, so env vars like the one mentioned, moz wayland, I have anv_video_decode there, QT Quick controls, QT scale factor, VK LOADER DEVICE SELECT etc. most env vars like this are perfectly fine to set globally, and perhaps even wanted

[oiaohm]

Unless you have a reason to *not* set them globally, there is no need to not put them in /etc/environment.

This one depends on your distribution.

Some distributions will be putting stuff in /etc/environment or have /etc/environment set by package as nothing that updates will restore so taking out what ever you put in that file. There is /etc/environment.d can be better to put a file in here if you need to global.

~/.config/environment.d advantage is that you don't end up in possible dispute with something a package you have installed has provided. There is no what distribution is this other than is systemd.