enabling the built in color profile desaturates colors quite a bit and does some kind of perceived brightness to luminosity mapping that desaturates bright / dark hdr content even more

It maps the colors to be more correct, and it does use the brightness info from the EDID for HDR content, so that checks out.

I think there must be something wrong with my screen since the hdr reduces saturation more than anything else

It might enable some sort of gamut mapping on the display side... HDR on monitors is really weird sometimes.

Side note, when I turn off hdr only from kscreendoctor the display stays in hdr mode until it turns off and on again, that didn't happen with nvidia

I think that's a bug in amdgpu. It should force a modeset on hdr change, but it doesn't.

That has pretty much nothing to do with the color profile, when colors look very desaturated on HDR screens, that's the driver messing up the colorspace signaling.

What GPU do you have? Both Intel and NVidia still have major problems with this.

Many displays (but not all, which is why it's not exposed in the GUI) also support doing HDR without additional colorspace signaling, you could try enabling only hdr and disabling wcg with kscreen-doctor. IMO the color part is the more noticeable benefit of HDR, but you could at least have functional HDR until your GPU driver is fixed.

Fedora just has

polkit.addRule(function(action, subject) {
    if ((action.id == "org.freedesktop.packagekit.package-install" ||
         action.id == "org.freedesktop.packagekit.package-remove") &&
        subject.active == true && subject.local == true &&
        subject.isInGroup("wheel")) {
            return polkit.Result.YES;
    }
});

in /usr/share/polkit-1/rules.d/org.freedesktop.packagekit.rules. If you put the same file in there, it should work.

Yes, and many distros have a polkit rule set up to allow installing or updating without a password. You can likely just copy it from Fedora or sth

Writing graphics code in a unified model is quite a bit different from the conventional x86 model.

It isn't. The difference is pretty small, and it's just optimizations for when copies can be skipped and not a radical change in the approach of how rendering is done.

Intel would need their own equivalent to Metal if they wanted to do a similar move.

Not at all. If big-ish changes were required, they could be exposed as Vulkan extensions.

I don’t know enough about Vulkan to say if it’s compatible with this kind of approach

Of course Vulkan, the graphics API used on all modern phones except Apple's, supports using integrated graphics efficiently.

the fact that 1.8 was working tells me that it is possible for a window manager to work well for nvidia

Nope, it's a race condition for which the visible effects can appear or disappear for plenty of reasons. The only fix is explicit sync, which is being worked on for wlroots

It's been possible for a long time, but yes, now you can do it intuitively in the shortcuts GUI

You can probably implement it in the script itself, but there's no external functionality to do it

Only thing not working for me is HDR (should be fixed in Plasma 6.1)

What's supposed to not work, and what am I supposed to have fixed in 6.1? There haven't been any major changes to HDR since 6.0

Changing the output config file should work, as long as KWin isn't running while you make the change (in which case the change will just be overridden)

Edit: Also, please make a bug report about this for KWin. It's probably not a KWin issue, but we can usually figure out where it's coming from

Debian still ships version 5

Debian ships 5.27.5 - it's not just not updating often, but it's not shipping bugfix releases (latest 5.27 version is 5.27.11!). I recommend to avoid it and maybe look at KUbuntu LTS instead

That sounds like your TV is temporarily disconnecting at random, or at least doing something that the GPU detects as a disconnect.

Most likely, AMD's hotplug detection is too aggressive. You can report that at https://gitlab.freedesktop.org/drm/amd/-/issues

Yes, that should be fixed in Plasma 6 - at least for Qt apps. For other apps it depends on the toolkit to have support for fractional scaling

No. Source 2 still uses some X11 specific stuff and has to be ported over to Wayland before it can work Wayland-native

Presumably, your merge request is about merging your fork master branch into the upstream master branch, right?

In that case, you have two options:

1. Go into the Gitlab settings of your fork, find the setting where branches are protected and disable the protection for your master branch
2. (the recommended way, at least for future merge requests) always create a feature branch, never work on master in the first place. You can create a branch from what you have right now on the command line with git checkout -b featurename. Then push that branch and create a new merge request for it

Are you on Wayland, or Xorg?

It is editable by default... Once you click on it, it turns into a normal text field

In a Plasma 6 Wayland session, Qt apps can make that behave as you'd expect, and we implemented it for plasmashell. I don't know if GTK has any support for that though