Plasma Wayland Protocols 1.16.0

[Konqi]

Plasma Wayland Protocols 1.16.0 is now available for packaging. It is needed for the forthcoming Plasma 6.3.

---

This is a companion discussion topic for the original entry at https://blogs.kde.org/2025/01/09/plasma-wayland-protocols-1.16.0/

[pallaswept]

I’d LOVE to know what this actually means:

• add power/performance vs. color accuracy preference

I understand that we are being given a trade-off switch… but what, in as much detail as possible, are we trading?

I’ve never seen anything like this before, which tells me every other desktop has been making this decision for me, and I think it’s great that KDE will let the user decide. I’d just like to know what either decision would give and take away, so that I can choose wisely.

[johnandmegh]

I imagine there’s more user-facing explanation to come as Plasma 6.3 approaches, but if you like the idea of looking at code commits and merge requests, this KDE Invent issue contains links to the different pieces (including the one referenced above) that are coming together to enable that feature: "power/performance vs. color accuracy tradeoff" feature (#256) · Issues · Plasma / KWin · GitLab

[pallaswept]

ngl I was hoping someone would spare me reverse-engineering things, but now I just feel lazy

TL;DR: I read all that and now I’m even more confused.

I think that what this is, is “do you want kwin to use more GPU, to get better colour?”, but I’m far from sure. In code, it’s called ‘colorpowertradeoff’ but I don’t see that this is actually about power usage or efficiency, it seems like the power usage being implied by the GPU usage?

I guess this comment sorta answers my question…

Right now, it’s only used for deciding if KMS offloading is acceptable, and for deciding the bpc of the shadow buffer

for now…

but it might be extended more in the future

and since

The compositor can do a lot of things that trade between performance, power and
color accuracy.

I guess I’m none the wiser.

Reading through the conversation between devs, I’m even less clear, now. I’m kinda fuzzy about what is meant by the options. We have a two-option choice to make, but there is talk of three parameters: Power efficiency, performance, and colour.

I saw references to selecting the choice of preferring power efficiency and performance, over colour… How does that work? Wouldn’t higher performance imply higher power usage? Or is the implication here, that processing colour will reduce performance of the desktop, thus reducing power use? But that doesn’t make sense, since it’s not like colour processing is going to result in the system sitting there doing nothing.

I did get this piece of concrete info out of it:

I now added reducing ICC profiles to matrix+shaper with KMS offloading if the preference is set to prefer power saving. With that, the ICC profile doesn’t have any performance impact anymore.

OK so that one feature (comment quoted above suggests that this is all there is to it, but this comment suggests this is an additional feature? Confused) we get the choice to process ICC profiles with less accuracy, which takes less performance, and I assume less power for that feature but not necessarily less power overall, it might even use more power overall, since the GPU is less busy doing colour correction, it might do more power-hungry work with what’s left over… So we could prefer power efficiency, but use more power and get higher performance (in everything but colour accuracy)…

I could go on, but I think I’ve demonstrated why I don’t find much clarity about what exactly this feature does… And then there’s the whole future aspect to this.

Expanding upon my layers of confusion, it’s not clear whether this only effects the desktop, or will it also effect other things like full-screen games?

At least I don’t feel so bad about being a little confused over what this is, since I saw the devs having conversations about which terminology best explains it. I still have no clue which option I’ll be selecting