No, only when you click on an input field and have it enabled in the system tray

The virtual keyboard is hidden by default, unless you're using touch. You can change that by setting the KWIN_IM_SHOW_ALWAYS=1 environment variable, until there's a proper setting for it

The github repo has tons of issues about the problems caused by the hacks (from the cursor not being recorded, to it not working in Flatpak, not working with virtual displays, to even preventing graphical sessions from starting!) with the suggested solution of just using the remote desktop portal... I don't know what the problem is, but it's not a lack of knowledge.

In the case of one project in paticular, that being the Sunshine game streaming project

That's a terrible example, because they completely ignore the many many years old standardized APIs (screen casting and remote desktop portals) that they could use, in favor of doing hacky and broken things that require root access instead.

Xwayland doesn't get input in some special way, it uses the exact same Wayland protocols to get input events as native Wayland apps. All claims about it being more complete or anything like that are nonsense.

Krita forces Xwayland because they have some X11 specific code they haven't bothered porting away from, that's all.

You don't need to use steamtinkerlaunch, putting gamescope --hdr-enabled --fullscreen -W width -H height -- %command% into the launch options is enough.

Will the Gnome version of Bazzite work for HDR on an Nvidia GPU, or for that matter any other OS as long as I’m using gamescope to run the game with HDR enabled?

Gamescope can't make a different compositor support HDR. Until Gnome supports HDR and the protocol used by gamescope, it won't work.

Closing the window during an update is supported, you don't have to worry about it. Discover continues running in the background, and shows a notification until the update is complete.

That is not NATO starting any war, anyone wirh the reading comprehension of a six year old understands that. Don't fall for Russian propaganda, FFS.

Yeah, it gets more blown out the bigger the difference between the sdr brighrness setting and the highlights is.

Support for HDR screenshots is hopefully something I can add soon-ish

How are you taking the screenshots? Spectacle might not capture HDR highlights well, but it should look all proper on SDR content

That's not really a Wayland thing, that's an (apparently badly implemented) attempt to bridge X11 apps to a permission system they were never written for.

With appropriate sandboxing of apps so they can't just LD_PRELOAD code into all other apps you run, yes.

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