KDE Plasma 5.13 Ships As The Best Plasma 5 Release Yet

[matthewtrescott]

Does Windows store common settings for all users? I thought it kept per-user settings on most things.

Not certain about input device settings, but certainly for display configuration.

[Vistaus]

Already arrived in KDE repositories in openSUSE LEAP 15

Also already arrived in Solus Unstable repositories.

[ResponseWriter]

Yeah, I tested Wayland session with 5.12 recently and it was segfaulting early. What's the story with it? Is it a Mesa or KDE bug?

Are you connecting over DisplayPort? And which model of GPU?

I'm writing this now in a wayland session on AMD CIK card (using amdgpu kernel module) connected over HDMI but over DP it does not start. I did recently try the staging-drm-next branch as suggested by another user but that didn't fix the issue. Now I have a little more information I can submit a bug report for this.

The Gamma settings don't appear to work on wayland but that I can live without since 'Night Colour' does.

[shmerl]

Hi ! Are you referring to boot time ? Are you referring to constant HDD spinning due to Baloo indexing ?

To many things. Awfully long log in time, freezes and stutters in the UI, hanging krunner and many more. Lot's of that stuff could be avoided by replacing synchronous I/O with async one and not making UI block on every disk call.

[shmerl]

5.13 had bunch of work on boot time, profiling things to identify sync I/O blockers that could be handled as async instead iirc. Anything else you had in mind that should be async that isn't? Also using a good disk I/O scheduler will help, BFQ for example should make a noticeable difference as a desktop user.

Log in time was a huge pain so far. I didn't test 5.13 yet, waiting for Debian testing to get it. But I'm also in the process of switching to NVMe to mitigate some of that slowness, so I might not have a chance to test it. One of the examples is constantly stuck krunner which freezes on some socket waiting (SSD won't help here, it's a bug that exposes sync design). Stutters in plasmashell caused by I/O are also not uncommon.

Good to know that there is some work being done to handle I/O more asynchronously.

[shmerl]

Are you connecting over DisplayPort? And which model of GPU?

Yes, DisplayPort / Sapphire Pulse AMD Vega 56.

[torturedutopian]

Anyone managed to get global menus to work with most apps in Neon ? Does work here with FF/TB and all KDE apps but not Libo, Clementine for instance. I haven't tweaked anything so far.

Looking forward to replicating this : https://twitter.com/NeoSiteLinux/sta...909060/photo/1

[polarathene]

To many things. Awfully long log in time, freezes and stutters in the UI, hanging krunner and many more. Lot's of that stuff could be avoided by replacing synchronous I/O with async one and not making UI block on every disk call.

One of the blog posts on improving the boot perf is here: http://blog.davidedmundson.co.uk/blog/plasma-startup/

I've run KDE 5.12 with Manjaro off a old Core 2 Duo(dual core no hyper threading, 2.8Ghz), r600g(256MB vRAM), 2GB RAM laptop system which used a USB 2.0 32GB drive for the disk(installed OS, not live image). It was pretty smooth and stutter free for the most part, but would periodicially for a brief moment freeze/stutter, presumably when it did disk I/O. I used a custom kernel(Liquorix) which seemed to improve things quite a bit, along with use of BFQ for disk I/O. I found that as long as I didn't cause any swapping to disk, I was pretty good(some distros might need to adjust the vm tunables in the kernel to reduce preference to swap and also disk flushing/buffer for I/O, which I also tuned due to the slow 16MB/s I/O on the USB 2.0 stick).

The only noticeable issues was video wasn't accelerated by default, couldn't seem to resolve that with FF iirc, but used an AUR package of chromium with vaapi support(ubuntu I think has this patch applied already, Chrome hasn't bothered to merge it for years for some reason but is meant to be sometime this year). And the other big cause of freezing the system(due to disk I/O) turned out to be the browser too, just one tab viewing youtube, and there is quite frequent disk read/write for some reason, even if you're not actively using the browser. Seemed to be profile or cache I think, there is another AUR package that'll move that disk data to tmpfs on your RAM with overlayfs and sync each hour(or when you close the browser) to disk. Now no problem.

Still booting isn't particularly fast, even with the autologin, it wasn't too pretty or usable for a while despite windows popping up and wallpaper eventually loading in etc, took a couple mins I think. Might be much better with 5.13 now, and I hadn't done any boot optimizations myself. You can see addressing it is important to KDE devs though

[miabrahams]

I haven't been following KDE (don't run it myself, but interested in trying). One of my main gripes with Linux (or rather X11) is the mixed DPi support, ie running a 4k and FHD display together without scaling issues, setting lower res on a monitor, fiddling with xrandr scaling and so on. I remember reading something about KDE looking to fix it in 5.11-12 but don't think they did. Does anyone know the current status of this?

It is fairly impossible to fix in X11 in a general way. The X server can't distinguish between different monitors, it just mashes them all into a mega-screen. Your desktop manager doesn't get to access this information. Even the simple feature of pinning your task bar to the edge or bottom of a monitor is unreliable for this reason. Per-monitor DPI is the #1 Wayland feature that I'm eager for.

If you want a polished KDE distro, it's only neon/kubuntu.

Or OpenSUSE.

[shmerl]

One of the blog posts on improving the boot perf is here: http://blog.davidedmundson.co.uk/blog/plasma-startup/

That's an interesting overview of various issues, thanks! I'll give a try to suggested profiling method, to see what actually eats the startup time for me.