I don’t want to just add another me too post, but I am also experiencing the same issue. Since the upgrade, I’ll receive a seemingly random notification and I notice all notifications have gone black, then shortly thereafter everything is frozen in kwin (but I do still hear sounds). I am able to go to a different TTY and reboot though.
Going to try to see if I can find a culprit in logs, but the only thing I see out of the norm is baloo using a ton of CPU. I’ve also migrated away from the Willow Dark Window Decorations, and just went with Breeze decorations. I’ll continue to monitor and see if I can find anything.
2 Likes
Since the update to 5.26 my bluetooth audio is not working. The headphones are connected but pulseaudio doesn’t show them as available. I’ve looked in the pulse/default.pa file to make sure the modules are loaded and reset pulse to no avail.
2 Likes
Having that one as well, I think it’s the same as:
Do you also have 3 monitors?
I did try reverting to default, but it still freezes everything up.
2 Likes
No, I’m only using one ultrawide monitor and an AMD videocard. I’ve been reading the kde bug report on resizable popups having issues with implicit width. When I look at journalctl, I see tons of these appearing when displaying notifications, and that is the last thing I see in the logs before the crash and having to open a new TTY.
Nov 03 15:55:08 Linux-ChaoSphere plasmashell[1029]: Could not find the Plasmoid for Plasma::FrameSvgItem(0x55ace568ed10) QQmlContext(0x55ace34bdc10) QUrl("file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
Nov 03 15:55:08 Linux-ChaoSphere plasmashell[1029]: Could not find the Plasmoid for Plasma::FrameSvgItem(0x55ace568ed10) QQmlContext(0x55ace34bdc10) QUrl("file:///usr/sharChaoSpheree/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/global/Globals.qml")
Nov 03 15:55:08 Linux-ChaoSphere plasmashell[1029]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationItem.qml:221:21: QML SelectableLabel: Binding loop detected for property "implicitWidth"
Nov 03 15:55:08 Linux-ChaoSphere plasmashell[1029]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationItem.qml:221:21: QML SelectableLabel: Binding loop detected for property "implicitWidth"
Nov 03 15:55:08 Linux-ChaoSphere plasmashell[1029]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationItem.qml:221:21: QML SelectableLabel: Binding loop detected for property "implicitHeight"
Nov 03 15:55:08 Linux-ChaoSphere plasmashell[1029]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/SelectableLabel.qml:38:5: QML TextArea: Binding loop detected for property "implicitHeight"
Nov 03 15:55:08 Linux-ChaoSphere plasmashell[1029]: file:///usr/lib/qt/qml/org/kde/plasma/components.3/ScrollView.qml:45:27: QML ScrollBar: Binding loop detected for property "visible"
Nov 03 15:55:08 Linux-ChaoSphere plasmashell[1029]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/NotificationItem.qml:221:21: QML SelectableLabel: Binding loop detected for property "implicitWidth"
This could just be my case, I happen to get a ton of notifications from my mobile using KDEConnect and email but I thought I should share. And I will also share I’m not using any third party application for notifications, just regular knotify.
2 Likes
I must be lucky, no problems on either 5.24, 5.25 or 5.26.
7 Likes
Hmm. I did experience some minor activity weirdness recently running 5.24.7. Just as a precaution I turned off activities for the time being. Maybe it was just a weird glitch.
2 Likes
Why are you all using rolling distro, I wonder? There are plenty of distros with fixed version of DE.
And in regard to bugs: write them to actual kde bugtracker if you want them fixed. And before that, do a clean install (in a VM or something) and see how Plasma works just fine (mostly).
1 Like
-
Because iteration-release distros have arbitrary “version freeze” policies, regardless of bugfixes from upstream. They may backport bugfixes to “system” libraries and packages, and make exceptions to things like web browsers, but for the most part its arbitrary. -
They also tend to lag behind other upstream software and projects.
-
They lack the AUR, which is underappreciated.
-
KDE/Plasma happens to be an outlier in recent days, due to their management and developers. (I’ve been through their bugtracker, even recently, and they tend to sit on their thumbs. Then they try to introduce a new “feature” which ends up compounding bugs that have yet to be addressed. I start to lose motivation to put the work into writing up a bug report, as do others I’ve communicated with in private over email. And no, they’re not even Manjaro users; we just happened to cross paths in certain bug reports.) Hence, why some of us want to be able to still use our computers in the meantime, and sticking with 5.24.x allows us this grace period.
We understand we have to eventually (sooner than later?) jump to 5.26.x or even 6.0.x.
But for now, this has been a net positive for my user experience.
5 Likes
I don’t think any of us could have foreseen this situation. I feel like it will resolve itself, so I am not worried. Meantime: Timeshift is my friend! 
6 Likes
Just giving my two cents:
Personally KDE has been a PITA for the past 1-2 years.
Most issues might be related to using nvidia, however the following issues really struck with me:
- No search results in application launcher - #6 by alkl
- Entire system randomly becomes unstable, windows flicker and sometimes stop responding - #11 by teo8976
- Meta key is no longer bringing up Plasma menu
- KDE Plasma 5.25 focus on the wrong window with Nvidia cards
- Can not set light theme for taskbar and drop down shell
- Number of concurrent streams error when installing themes
- Ark 7zip and zip compression not working properly and crashing Dolphin
Don’t get me wrong, most problems have been fixed over the last 1-2years, however the general tendency to ship “”“stable”“” software (on the side of KDE) has been a nerve racking ride.
The main problem I see are the amount of really weird inconsistent behavior across the board - some people might have no issue at all with 5.24, whereas 5.24 was painful for me. I liked 5.25 more than 5.24 - however lot’s of people had more issues.
There are still some fundamental broken / buggy thinks like putting monitors to sleep and glitching windows / (minor) visual bugs.
My personal KDE experience the entire time was to find workarounds for newly added bugs with each release.
4 Likes
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?
2 Likes
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.
3 Likes
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.
2 Likes
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.
4 Likes
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. 
2 Likes
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”.
4 Likes
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 …
16 Likes
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”.
5 Likes