KDE Plasma 6.0 Lands More Performance Optimizations, Better Wayland Gaming Experience

[phoronix]

Phoronix: KDE Plasma 6.0 Lands More Performance Optimizations, Better Wayland Gaming Experience

KDE developers continue adding new functionality and performance optimizations for the Plasma 6.0 desktop that is aiming for its release in early February...

https://www.phoronix.com/news/KDE-Plasma-6-Better-Gaming

[timofonic]

On the other end, amazing KWinFT efforts are largely ignored by upstream due to be developed by an external developer. Even Valve stopped financing.

What a shame!

[Steffo]

On the other end, amazing KWinFT efforts are largely ignored by upstream due to be developed by an external developer. Even Valve stopped financing.

What a shame!

Why is it a shame? What's the point of financing two KDE compositors? When I read forum posts about KWinFT, I don't see the promise of stability when users report crashes or black screen.

[doomie]

Latency reduction! !!! Perhaps. I'll be looking forward to testing this.

[slagiewka]

Better gaming experience on Wayland - finally something that I'll be really looking forward to in 6.0. Not that it's currently bad or that 6.0 features are too.

The default keyboard shortcut for launching the activity switcher has changed from Meta + Tab to Meta + A.

My first (or one of firsts) thing to do in a fresh session - disable Meta + Tab activity switching. I would disable activities all together, if I could.
They are planning on using Meta + Tab to control the refined overview effect. And I'm not too sure about this. For me Meta + Tab is for workspaces (virtual desktops) what Alt + Tab is for windows - iterating over them and quickly switching.

[relsi1053]

Why is it a shame? What's the point of financing two KDE compositors? When I read forum posts about KWinFT, I don't see the promise of stability when users report crashes or black screen.

you don't see the promise of stability because it sucks

[kiffmet]

On the other end, amazing KWinFT efforts are largely ignored by upstream due to be developed by an external developer. (…)

KWinFT by now has a vastly different codebase than KWin. While it started as a fork, it has since seen major refactors/restructuring and even transitioned to be based on wlroots. Just pulling in patches from one into the other is no longer possible in most cases.

AFAIK, that "external developer" used to be part of the KWin team, but left and created the fork, since his views on how KWin should be structured and which future direction the development takes weren't shared by the majority of the other devs working on that component, which led to frequent quarrels.

[timofonic]

KWinFT by now has a vastly different codebase than KWin. While it started as a fork, it has since seen major refactors/restructuring and even transitioned to be based on wlroots. Just pulling in patches from one into the other is no longer possible in most cases.

AFAIK, that "external developer" used to be part of the KWin team, but left and created the fork, since his views on how KWin should be structured and which future direction the development takes weren't shared by the majority of the other devs working on that component, which led to frequent quarrels.

Sectarian attitudes are sometimes common in very big FOSS projects, unfortunately. Both KDE and GNOME suffer from it.

I think using wlroots and improve that common codebase should be the norm between most DEs/WMs, not the exception.

[polarathene]

On the other end, amazing KWinFT efforts are largely ignored by upstream due to be developed by an external developer. Even Valve stopped financing.

What a shame!

I reported this in July 2022, plenty of information and it should be easy enough to reproduce in QEMU or VMware, but despite all that no engagement:
X11 renders only a cropped top-left region at 1024x768 (regardless of resolution set) (#271) · Issues · KWinFT / KWinFT · GitLab

That doesn't instill much confidence. On the releases end, the last was in Feb 2023 for Plasma 5.27 release, there won't be another KWinFT release until Plasma 6.0 is out.

When I tried building for that a month or so ago, it was full of build errors where I had to dig a bit to figure out what Plasma repos to clone and build or packages to modify (mostly due to the shift to Plasma 6 which was relying on git packages).

I think it's a cool project, but I don't know how well it'll manage to keep up with kwin and not breaking. Even my issues aside, it lacks parity in some features and I understand why but if they want to improve adoption first it needs to be somewhat reliable, especially with availability to try. Gitlab is also a slight drawback I imagine, Github is easier to attract more contributors, not just because of popularity but because Gitlab has for many years been ignoring UX issues like proper notifications page, you can only get notified by email which is ridiculous.

[polarathene]

The change for Flatpak install issue seemed a bit odd. They state an install would use 60-100 fds, so they chose to limit concurrency to 4 to stay under the default 1024 limit?

- 1024 is the soft limit, and the hard limit in the kernel is default to 4096.
- There is a variety of other influences depending on context that can adjust that though.
- systemd since v240 (2018Q4) for example defaults to 1024 soft and 524288 hard, while also boosting `fs.nr_open` limit from 2^20 to 2^30 (this represents 'unlimited' / infinity). The last one is patched out by Debian last I checked though, keeping it at 2^20 (IIRC it was due to a bug with their patched PAM package that nobody is bothering to resolve).
- If there is no ability to influence the hard limit being raised, you should still be able to raise to 4096 (unless the software is relying on those legacy calls that behave badly with the fd limit exceeding 1024, `select()` is apparently one of those).

Golang will raise to the hard limit implicitly since 1.19 (and for child processes restore to the original soft limit to avoid problems). While Docker / Containerd have long shipped systemd services with `LimitNOFILE=infinity`, that has been very bad to have such a high soft limit in a container environment since all processes inheriting that can have major slowdowns (usually daemons sanitizing during init by iterating through all potentially open FDs and sending a close syscall). That's been addressed for Docker v25, still waiting on containerd maintainers to approve for their next release.

Maybe the affected code for Discover is restrained to the 1024 limit for a reason, but it may be more likely that nobody felt confident about exceeding that? This is a limit per process IIRC? It's not the full system limit, that would be `fs.nr_open` (and possibly another related one, both really big so not a concern). Probably could have requested to raise the soft limit, and if concerned about exceeding whatever limit is used, query that and apply the appropriate concurrency limit?

To be fair, similar happened with Docker almost a decade ago, and that is how the `LimitNOFILE=infinity` "fix" landed. A concurrency limit of 4 wouldn't work there, but that was excessive to set (at the time not as bad since fs.nr_open would only be 2^20 at most), but they should have used a soft limit of 1024 and raised it only for their process. Which Go handled implicitly with the arrival of 1.19.

That said the whole issue here could be more upstream related, and KDE is just working around it?

---

Michael, your ads are blocking the "Post Reply" button, makes it less tolerable to allow them