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.

Of course apps can and do restore their window sizes. Don’t spread misinformation

Yes, for now someone has to be logged in and have the server running

To maybe prevent a catastrophe: The system is not able to restore virtual desktop assignments yet, it only starts the apps you had open before.

Just click the button in the sddm settings page

There have been incidents involving malicious code downloaded through Plasma global themes.

No malicious code was involved, just buggy code.

That’s just a law of computers, the default arrangement of monitors must always be wrong.

You can just sync your Plasma settings to SDDM though, and it’ll use the same output settings as your session

KDE did bother, this does neither happen with KScreenlocker, nor do non-screenlocker windows show in another way, because the screen locker is integrated with the compositor.

If the compositor crashes or gets disabled somehow ofc though, that integration doesn’t help either and you have to rely on a mountain of bad hacks as well as the hope that the screen locker doesn’t also crash for nothing to happen in that case, but it’s as close to secure screen locking as you get on Xorg… in the end the solution for secure screen locking is still Wayland.

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

S3 is standby. Hibernate is S4

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

Setting the speed to the max does turn them off

The only effects relevant for performance are blur and background contrast. Turn those off if you feel the system is slow, maybe increase the animation speed and you’re done

Most displays provide settings to modify the colors of your screen; mine has like 10 different “picture modes” that strongly modify gamma curves, colors and the whitepoint. The EDID only describes colors of one of them, so if you change display settings, the data no longer applies.

More generally, the information isn’t used by Windows or other popular video sources by default, so manufacturers don’t have much of an incentive to put correct information in there. If it doesn’t make a difference for the user, why would they care? Some displays even go so far as to intentionally report wrong physical size information, to make Windows select the default scale the manufacturer wants to have on that display (or at least that’s what I think is the case with my cheap AliExpress portable monitor)…

That’s not to say that the information is actually often completely wrong or unusable, but if one in tenthousand displays gets really messed up colors because we toggle this setting on by default, it’s not worth it. We might add some heuristics for detecting at least usable color information and change this decision at some point though

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

it falls to each and every individual app to (re)implement everything: accessibility, clipboard, keyboard, mouse, compositing etc. etc.

I haven’t read so much nonsense packed in a single sentence in a while. No, apps don’t implement any of these things themselves. How the fuck would apps simultaneously “implement compositing themselves” and also neither have access to the “framebuffer” (which isn’t even the case on Xorg!) nor information about other windows on the screen?

Please, don’t rant about things you clearly don’t know anything about.