Multi monitor VRR has never been problematic in Wayland, but the NVidia kernel driver doesn’t support it at all yet, Xorg or Wayland doesn’t matter.

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

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

No malicious code was involved, just buggy code.

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.

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

They are afaik not allowed to exist with USB C. And except for some very few very sketchy manufacturers, it’s also luckily not a thing in practice.

The warnings you see are caused by https://github.com/ValveSoftware/SteamVR-for-Linux/issues/616. Maybe disabling async reprojection will help you too

Yes, it is a KDE shortcut, a kwin_x11 shortcut to be more specific. It’s not a thing with kwin_wayland, and so it most certainly did not help or do anything for you - unless you’re not actually using the Wayland session of course.

That shortcut does nothing on Wayland. What you’re experiencing is either placebo, or you’re not using Wayland

wasn’t it thought for kiosk applications, then extended to login screens

No, that’s a really pervasive myth, spread by trolls.

Wayland - or rather, Weston - first came into use in the embedded scene because things are a lot simpler to change there and the limitations of Xorg even more unforgiving… But it was never designed for that purpose alone, it was always meant to replace Xorg everywhere.

It is repeated in every single damn “Linux phone” thread, and in every single thread an answer like this is needed: No, it fucking isn’t. You know exactly what everyone means, stop being a dick about it.

Yes, though it’s not exactly relevant to your wishes… KWin has supported VRR for almost three years now, and HDR for 9 months too (not released yet ofc). I’ve been playing all my HDR capable games in HDR mode for the past few months.

For me, this is more about making it more efficient and make it work better by default.

until apps can declare on a simple config file what paths they require

They can, and always could. Apps aren’t doing it, most Flatpaks have just blanket “allow ~/Downloads” or “allow all of home” permissions by default - or no file permissions, and you have to go grant them manually yourself.

Again, unless apps actually support it, no matter how good the security system is, it won’t work out.

Instead of bluntly blocking things why can’t Flatpak just simulate a full environment and just prompt the user whenever some application wants to read/write to file / unix socket at some path?

Because the user getting a hundred popups on app start for various files the app needs isn’t exactly a usable experience. Also, blocking the app’s main thread (which is the only way you could do this) is likely to break it and cause tons of user complaints too.

Aside from apps using the APIs meant for the purpose of permission systems, there’s no good way to make it work.

The best part is that instead of doing what Flatpak does (just blocking things and leaving the user unable to to anything) the system will prompt you for a decision.

No, Flatpak isn’t the problem here, portals for these things exist. The problem is that apps would have to use them, and unlike Apple, there’s noone restricting the old / unrestricted ways of doing things… So apps usually don’t port over to the portals.

Even where the unrestricted APIs stop working, like with screen capture and Wayland, apps are excruciatingly slow to port over, because they don’t get kicked from app stores for it, and because many users can still fall back to using the old system.

Plasma never had this issue in any release, VRR has worked exactly the same since it was introduced until Plasma 6 (where there’s some improvements for the “always” mode)

FreeBSD isn’t working on a Wayland port, that’s already happened. The Plasma Wayland session has supported it for quite a while… KDE even runs a CI job on FreeBSD for every merge request, where kwin_wayland autotests are run.

Considering the amount of complaints we got when something broke recently though (which is to say, none), it doesn’t look like it has a lot of users