Are you implying that the term “rolling-release” would be synonymous with “buggy and unstable”?
If so, then I think you misunderstand a few things with regard to GNU/Linux distributions.
Are you implying that we didn’t, even though some of us have reported on the other thread that we’ve already done that?
Although I haven’t tried anything other than KDE recently, I would bet money that that bug is not in KDE, but way deeper, I think even deeper than Xorg, like in the kernel (whether it’s a bug or a wrongly chosen default parameter in the boot configuration), or something pretty low-level. This is just a gut feeling though.
No, it is most definitely not a kernel bug, nor is it an X.Org bug, because those same problems also occur on Wayland, and with a whole variety of kernels. And it has also been observed on ARM, so it’s not even specific to x86-64.
Besides, Plasma does not run in kernel space, and the only X.Org component that does is the direct rendering subsystem — Wayland runs a lot more in the kernel’s address space. Everything else runs in ring 3 of the processor — i.e. userspace — and in isolated memory address spaces.
No, it is most definitely not a kernel bug, nor is it an X.Org bug, because those same problems also occur on Wayland,
Oh ok.
So that means none of the suggestions that I got in that thread have any hope whatsoever of working.
So far updating the kernel didn’t help (that by itself wouldn’t rule out a kernel bug of course) and I’ve applied one of the suggested edits to kernel parameters and waiting to see if the issue still shows up. If you’re right then it will.
I’m just surprised to learn that things that seem so low-level as responding to mouse and keyboard and flickering of the screen, are handled at such a high level as KDE. I thought they were more like, I don’t know, at the level of interrupts and graphic drivers or something.
Well, it’s a bit more complicated than that. When it comes to input devices like a keyboard and mouse, there’s a pecking order. Keyboards and mice are hardware devices, and the part of the operating system that handles hardware is the kernel.
However, with the exception of direct kernel commands — read: the Magic SysRq keys — the kernel will normally forward all keyboard input to the next item in line, which is the terminal.
Most people don’t know this, but the terminal itself recognizes certain keyboard input as shortcuts to terminal functions. For instance, Ctrl+D sends an end-of-transmission character, which, if you’re looking at a command prompt, the terminal will translate into a logout command. Another example is Ctrl+L, which the terminal interprets as a clear command — i.e. it’ll clear the screen.
There are more shortcuts like that, which are all handled by the terminal, rather than by whatever program is running in that terminal. And if the keyboard input does not match a terminal shortcut, then the terminal will forward the keyboard input to the program running there.
If you’re in a GUI session, then the next thing in line — the program running in that terminal session — is your display server, i.e. X11 or Wayland. With the exception of one or two specific shortcuts that the display server handles itself, every other input is again forwarded from there onto the next layer, which is your desktop and/or your window manager.
And only if the keyboard input at that point is not a desktop-specific shortcut will the desktop or window manager forward the keyboard input to the last layer, which is a graphical application that you have open and that has focus — i.e. it is the “active” application — such as a browser, a word processor or a terminal window.
As Manjaro has always said, as many forum members have said and Manjaro prides itself on, Manjaro is a curated rolling release:
And, sadly, as @Aragorn have said, the newbies demanded 5.25, which completely wrecked the curated part. As I’ve previously said, and still stick with, if you don’t want to wait, there are other branches out there. Even other non-curated rolling release distributions. Or as you’ve said yourself, fixed release distributions.
But I’m obviously wrong, so I’ll shut my yap. 
Thought i chime in again because on unstable (native) install the Settings got again reset with no apparent reason, out of nowhere, to a very funky “default” state. It is so bonkers that makes me feel i never used KDE Plasma in my life, that i don’t know what i’m doing. Well, what a wonderful chance to unwillingly start over from “fresh”.
same happens to me too.
ridiculous. because of kde’s unstable updates I may leave it for XFCE.
*I’ve installed envycontrol to switch GPU from NVIDIA to integrated. Now I try this mode if helps against to the bugs.
Kwin will break as soon as the Qt 5.15.7 updates will hit stable branch. You can always have a look at Arch Upstream changes for kwin. The second factor may be issues with frameworks updates.
KDE software is like this: You have frameworks, plasma and apps (gear - don’t know why the new name, but anyway). Each of those elements play closely together. Some frameworks update already broke 5.24.x series. That is why Ubuntu and others who have fixed DE versions also won’t update frameworks.
Maintaining LTS releases might be hard as you have to know your shareholders - distros actually using it. Manjaro is non of those. Having that github was only some side project of mine as some Manjaro staffers had issues with 5.25.x updates.
Also there is a reason why I use XFCE as my working DE for maintaining this distro as Lead Developer. Anarchy sometimes works but having a more company like structure can be better. Gnome development is totally different and XFCE development is something completely else. Each has its pros and cons. XFCE has a very small developer group and Xubuntu as main stakeholder. Even there they ship 4.17.x development releases. At some point when we shipped the latest git-master packages as overlay packages a lot of people out there got in love with XFCE and it showed that even random commits didn’t break that DE as other DEs might have.
Then there are the crazy daily commit builds we call kde-unstable. Those are mostly for KDE developers as it really may break stuff. We started that as we work closely on Plasma Mobile with them, a small group doing the Phone/Tablet UIs. There we also have breakage as the main focus is still on desktop mode. So even within KDE development there is some cat and mouse game. Anyway, KDE developers are super friendly and also fast in fixing issues when they face them also. Also you can decide as a developer what issues or features are more important to your project and maybe your userbase. In the end a friendly communication bi-directorial is always key.
The third issue are debug symbols. Arch used to have non of them. They lately added a feature via DebugInfoD. You might use that partly with our unstable branch, as you have to be as close as possible with your packages to Arch upstream. Manjaro on the other hand would need to establish some for our branches, which might not happen in near future at all. On ARM side the debug packages are simply added to the main repositories, which blows needed storage space up a bit. So we can distribute those packages there but might loose some mirrors in that remark. Also most Arch-based issue reports are based on Manjaro - based on popularity I guess. And since developers love their debug symbols those bug reports without them are mostly garbage for trace the issue in code base, hence Manjaro issues might be lower prioritized based on that. You may want to reproduce it on pure Arch and send in with debuginfod enabled …
KDE has more or less a 3 step cycle of development: Feature release, Feature release, Polish release. So 5.24 was a release to polish the user experience based on the past feature releases before it. Also since Kubuntu and Suse is using it 5.24 might be more stable than others. 5.25 was more or less a new set of new stuff getting added, which you can also read in the announcement. So holding it back on our end on stable branch gave us some entry in KDE reddit. Since we did that I reported issues after updates of frameworks directly as it was not known upstream that Manjaro is still on 5.24 back then.
Also you can’t please everyone. If you hold back a DE release based on some issues few might have you will loose other users who want to have the new features. If the new release is too buggy noone is happy about it. So you have to find a middle way. Since most of us use either Laptops or one Monitor, those hard desktop use cases like Multi-Monitor-Support is really low prioritized on our end during testing and even on upstream with development, as there also Laptops are the main focus.
Some might have noticed the little handheld some talk about. Well the company behind it froze Arch since January 2022. So we have Plasma 5.23.5 and Frameworks 5.90.0 there. So you have a really static base and you only update Kernels, Mesa and Audio-Stack. I totally get that. As a company you want to have a static base and work only on the features you want to prioritize on your product and use the DE as a solid base. When there will be an update to Plasma and Frameworks I don’t now as that would mean to either get a newer snapshot from Arch or start to compile your own packages. But there is always flatpaks to get newer software at least to sort out some issues.
So the only way to improve Plasma and opensource in general is a good communication with all participants and report issues as best as possible upstream. Those me too posts in a random forum like here doesn’t help at all. KDE developers have no time to look at downstream distro forums. Some have accounts and do, but not all. So if more than one person have the same issue, simply add more information on existing issue reports to make them more heavy in demand to be fixed. In the end the development is community driven. More people spending their free time to work on a project the better. And you don’t have to be a developer to do that.
Even testing early software or switching to testing and unstable branches here also helps. Then you hit the issues first before the stable branch users do. If you report and get into a dialog with upstream developers those issue might get fixed before we ship them to everyone else. And if some is really broken then speak up and explain why it is better to have some more stable as in stability than fancy new features …
I really appreciate comments like these from philm. It gives you an insight on that there’s more to maintaining a distro than just “flipping a switch”.
@Aragorn thank you for your message. For your information I’ve just updated to 5.26.x this evening - I didn’t take the dive and go back to 5.24.x after all…!
The slight niggles I experienced with 5.24, two of which being notably the desktop theme above the taskbar taking forever to charge as was the case for the GUFW firewall GUI upon system start up/rebooting(plasma crashing?), are totally absent as of this moment in time.
I’m currently keeping an eye out, of course…
Thanks to all for the great work 
Semper Fi!! 
Service post:
The freezing and “crashing” of kwin can be found on the following KDE bug tickets:
*UPDATE
Switching to Integrated GPU did not help, issues and bugs still occurring for KDE 5.26.2 on my side.
Kwin unresponsiveness and Plasma freezing occur when my stacked notifications arrive to the desktop after lit up the laptop. It seems Plasma and Kwin cannot handle stacked tasks when all come in a short period.
This one’s fresh as of today. 
Hoo boy. I suppose the Nouveau driver is equally vulnerable then. (Which is what I am using.)
*2nd UPDATE
I’ve gone back to Kernel 5.15.76-1 yesterday and still on Integrated GPU also disabled desktop notifications. Today when I lit up my laptop from sleep mode after hours no any glitch, unresponsiveness or freezing.
In normally, later than update of KDE 5.26.2 I could not use my laptop after stacked notifications appeared on my screen, KDE was going to frozen mode what even CTRL + ALT + F2/F3… not responding.
Issues seems related to Notifications-Kernel-GPU combinations.
Weird but disabling notifications yeah that helped me.
System:
Kernel: 5.15.76-1-MANJARO arch: x86_64 bits: 64 compiler: gcc v: 12.2.0
parameters: BOOT_IMAGE=/boot/vmlinuz-5.15-x86_64
root=UUID=278a86b1-7436-448c-929d-fa62c972f0b1 rw ipv6.disable=1 quiet
apparmor=1 security=apparmor udev.log_priority=3 acpi_backlight=vendor
Desktop: KDE Plasma v: 5.26.2 tk: Qt v: 5.15.6 wm: kwin_x11 vt: 1 dm: SDDM
Distro: Manjaro Linux base: Arch Linux
Machine:
Type: Laptop System: Acer product: Nitro AN515-44 v: V1.04
serial: <superuser required>
Mobo: RO model: Stonic_RNS v: V1.04 serial: <superuser required>
UEFI: Insyde v: 1.04 date: 02/04/2021
Battery:
ID-1: BAT1 charge: 42.0 Wh (79.4%) condition: 52.9/58.8 Wh (90.0%)
volts: 16.4 min: 15.4 model: SMP AP18E7M type: Li-ion serial: <filter>
status: N/A
CPU:
Info: model: AMD Ryzen 7 4800H with Radeon Graphics bits: 64 type: MT MCP
arch: Zen 2 gen: 3 level: v3 note: check built: 2020-22
process: TSMC n7 (7nm) family: 0x17 (23) model-id: 0x60 (96) stepping: 1
microcode: 0x8600103
Topology: cpus: 1x cores: 8 tpc: 2 threads: 16 smt: enabled cache:
L1: 512 KiB desc: d-8x32 KiB; i-8x32 KiB L2: 4 MiB desc: 8x512 KiB L3: 8 MiB
desc: 2x4 MiB
Speed (MHz): avg: 1894 high: 3299 min/max: 1400/2900 boost: enabled
scaling: driver: acpi-cpufreq governor: performance cores: 1: 2915 2: 1397
3: 1808 4: 1515 5: 2484 6: 1583 7: 1397 8: 1885 9: 3130 10: 1497 11: 3299
12: 1398 13: 1453 14: 1755 15: 1397 16: 1398 bogomips: 92662
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Vulnerabilities:
Type: itlb_multihit status: Not affected
Type: l1tf status: Not affected
Type: mds status: Not affected
Type: meltdown status: Not affected
Type: mmio_stale_data status: Not affected
Type: retbleed mitigation: untrained return thunk; SMT enabled with STIBP
protection
Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via
prctl and seccomp
Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer
sanitization
Type: spectre_v2 mitigation: Retpolines, IBPB: conditional, STIBP:
always-on, RSB filling, PBRSB-eIBRS: Not affected
Type: srbds status: Not affected
Type: tsx_async_abort status: Not affected
Graphics:
Device-1: AMD Renoir vendor: Acer Incorporated ALI driver: amdgpu v: kernel
arch: GCN-5.1 code: Vega-2 process: TSMC n7 (7nm) built: 2018-21 pcie:
gen: 4 speed: 16 GT/s lanes: 16 ports: active: eDP-1 empty: none
bus-ID: 05:00.0 chip-ID: 1002:1636 class-ID: 0300 temp: 40.0 C
Device-2: Quanta HD User Facing type: USB driver: uvcvideo bus-ID: 3-3:3
chip-ID: 0408:a061 class-ID: 0e02
Display: x11 server: X.Org v: 21.1.4 compositor: kwin_x11 driver: X:
loaded: amdgpu unloaded: modesetting alternate: fbdev,vesa dri: radeonsi
gpu: amdgpu display-ID: :0 screens: 1
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22")
s-diag: 582mm (22.93")
Monitor-1: eDP-1 mapped: eDP model: Najing CEC Panda 0x004d built: 2019
res: 1920x1080 dpi: 142 gamma: 1.2 size: 344x194mm (13.54x7.64")
diag: 395mm (15.5") ratio: 16:9 modes: max: 1920x1080 min: 640x480
API: OpenGL v: 4.6 Mesa 22.2.1 renderer: RENOIR (renoir LLVM 14.0.6 DRM
3.42 5.15.76-1-MANJARO) direct render: Yes
Audio:
Device-1: AMD ACP/ACP3X/ACP6x Audio Coprocessor
vendor: Acer Incorporated ALI driver: N/A alternate: snd_pci_acp3x,
snd_rn_pci_acp3x, snd_pci_acp5x pcie: gen: 4 speed: 16 GT/s lanes: 16
bus-ID: 05:00.5 chip-ID: 1022:15e2 class-ID: 0480
Device-2: AMD Family 17h/19h HD Audio vendor: Acer Incorporated ALI
driver: snd_hda_intel v: kernel pcie: gen: 4 speed: 16 GT/s lanes: 16
bus-ID: 05:00.6 chip-ID: 1022:15e3 class-ID: 0403
Sound API: ALSA v: k5.15.76-1-MANJARO running: yes
Sound Server-1: JACK v: 1.9.21 running: no
Sound Server-2: PulseAudio v: 16.1 running: yes
Sound Server-3: PipeWire v: 0.3.59 running: yes
Network:
Device-1: Realtek vendor: Acer Incorporated ALI driver: r8169 v: kernel
pcie: gen: 1 speed: 2.5 GT/s lanes: 1 port: 2000 bus-ID: 03:00.0
chip-ID: 10ec:2600 class-ID: 0200
IF: enp3s0 state: down mac: <filter>
Device-2: Intel Wi-Fi 6 AX200 driver: iwlwifi v: kernel pcie: gen: 2
speed: 5 GT/s lanes: 1 bus-ID: 04:00.0 chip-ID: 8086:2723 class-ID: 0280
IF: wlp4s0 state: up mac: <filter>
Bluetooth:
Device-1: Intel AX200 Bluetooth type: USB driver: btusb v: 0.8 bus-ID: 1-4:2
chip-ID: 8087:0029 class-ID: e001
Report: rfkill ID: hci0 rfk-id: 7 state: down bt-service: enabled,running
rfk-block: hardware: no software: yes address: see --recommends
Drives:
Local Storage: total: 476.94 GiB used: 343.87 GiB (72.1%)
SMART Message: Unable to run smartctl. Root privileges required.
ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Western Digital model: PC SN530
SDBPNPZ-512G-1014 size: 476.94 GiB block-size: physical: 512 B
logical: 512 B speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter>
rev: 21103900 temp: 30.9 C scheme: GPT
Partition:
ID-1: / raw-size: 153.02 GiB size: 149.56 GiB (97.74%)
used: 117.9 GiB (78.8%) fs: ext4 dev: /dev/nvme0n1p4 maj-min: 259:4
ID-2: /boot/efi raw-size: 1024 MiB size: 1020 MiB (99.61%)
used: 43.4 MiB (4.3%) fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1
Swap:
Kernel: swappiness: 10 (default 60) cache-pressure: 50 (default 100)
ID-1: swap-1 type: partition size: 2 GiB used: 55.1 MiB (2.7%)
priority: -2 dev: /dev/nvme0n1p5 maj-min: 259:5
Sensors:
System Temperatures: cpu: 58.5 C mobo: N/A gpu: amdgpu temp: 40.0 C
Fan Speeds (RPM): N/A
Info:
Processes: 421 Uptime: 23h 40m wakeups: 6 Memory: 15 GiB
used: 7.84 GiB (52.3%) Init: systemd v: 251 default: graphical
tool: systemctl Compilers: gcc: 12.2.0 clang: 14.0.6 Packages: 1651
pm: pacman pkgs: 1607 libs: 412 tools: pamac pm: flatpak pkgs: 38 pm: snap
pkgs: 6 Shell: Zsh v: 5.9 default: Bash v: 5.1.16 running-in: konsole
inxi: 3.3.23
OS: Manjaro Linux x86_64
██████████████████ ████████ Host: Nitro AN515-44 V1.04
████████ ████████ Kernel: 5.15.76-1-MANJARO
████████ ████████ ████████ Uptime: 23 hours, 28 mins
████████ ████████ ████████ Packages: 1607 (pacman), 38 (flatpak), 6 (snap)
████████ ████████ ████████ Shell: bash 5.1.16
████████ ████████ ████████ Resolution: 1920x1080
████████ ████████ ████████ DE: Plasma 5.26.2
████████ ████████ ████████ WM: KWin
████████ ████████ ████████ WM Theme: Nordic
████████ ████████ ████████ Theme: Breath2 2021 Dark [Plasma], WhiteSur-Dark [GTK2/3]
████████ ████████ ████████ Icons: kora [Plasma], kora [GTK2/3]
Terminal: konsole
CPU: AMD Ryzen 7 4800H with Radeon Graphics (16) @ 2.900GHz
GPU: AMD ATI 05:00.0 Renoir
Memory: 7521MiB / 15362MiB
I temporarily “fixed” the issue, by completely disabling all plasma notifications.
Simply turn on don’t disturb until you manually enable it again.
I have been following this thread and I find it rather strange
What is your differences?
What is the difference betwenn my system and yours?
Let me layout my system
The same problems are being reported on new installations, and on existing installations without any custom theming at all.
While it is true that some themes would be problematic because they were created for Plasma versions older than 5.12, newer themes should be fully compatible, and so should widgets be that were created by the KDE developers themselves.
If Plasma were intended to be used without any customizations at all, then the KDE developers should themselves not offer any means to customize it. 
I agree on the contradictons - but sometimes there’s very little to go on 