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.

What kind of flickering? Does the display support adaptive sync? If so, try turning that off

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.

For Netflix there’s a browser extension that does it, but I don’t know of a solution for other streaming services

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

Also, your blog is fantastic, I’m always happy when there’s a new post =)

Thank you, I’m glad you like it!

I feel like in SDR mode, the OLED is pushing brighter images. I almost feel like it’s underselling the capabilities at 270, but does so to give pixels a rest every now and then, in the hope that the bright spots don’t stay stationary on the screen. It’s a wild guess, I have no idea.

It’s certainly possible, displays do whacky stuff sometimes. For example, if the maximum brightness in the HDR metadata matches exactly what the display says would be ideal to use, my (LCD!) HDR monitor dims down a lot, making everything far, far less bright than it actually should be.

KWin has a workaround for that, but it might be that your display does the same thing with the reported average brightness.

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.

I understand that it’s an absolute brightness standard, not like the relative levels in SDR

The standard is also relative brightness actually, though displays (luckily) don’t implement it that way.

why does it end up washing out colors unless I amplify them in kwin? Is just the brightness absolute in nits, but not the color?

It depends. You might

• have a driver bug. Right now only AMD has correct color space communication with the display, that doesn’t work correctly on Intel and NVidia yet
• have a display that does a terrible job at mapping the rec.2020 color space to the display
• be just used to the oversaturated colors you get with the display in SDR mode

Why does my screen block the brightness control in HDR mode but not contrast?

Because displays are stupid, don’t assume there’s always a logical reason behind what display manufacturers do. Mine only blocks the brightness setting through DDC/CI, but not through the monitor OSD…

Why is my average emission capped at 270nits, that seems ridiculously low even for normal SDR screens as comparison

OLED simply gets very hot when you make it bright over the whole area, the display technology is inherently limited when it comes to high brightness on big displays

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.

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.

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

Just use Wayland, then you don’t have to care about this

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

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.