After today’s updates, using the mouse wheel over the left hand side main menu section of the “system settings” window of KDE Plasma, crashes the system settings window. A very interesting bug indeed.
Bug report found:
https://bugs.kde.org/show_bug.cgi?id=504074
PS: If you scroll over the application launcher (start menu) the same crash happens.
That report is a duplicate of a Resolved Bug.
How can a previously resolved bug manifest itself again?
It’s same bug reported by another person who didn’t bother checking to see if the bug had already been reported. Something that also happens on here a lot too.
Hi,
Thank for your feedback, I tried to reproduce the reported issue before and after the Updates, nothing go wrong on plasma.
Devices => Odroid c2, Odroid n2, Odroid c4, Odroid m1 not tested.
The devices are running on Wayland.
You will convince me to buy odroid devices. We on the RPI side deal with a lot of muck while you enjoy problem-free computing 
I’m not an Odroid devices sealer, just an ARM devices user
But, by default on x86 & ARM devices, I set the Plasma desktop as follow :
I disable all the desktop effect
System settings → Window management → Desktop effect ( I disable everything possible)
I don’t modify the animation speed, 50 % by default
System settings → Quick settings → Animation speed (in the middle to obtain 50 %, the default settings)
Curious to know your feedback with the above settings.
I had this issue yesterday on x86_64 unstable branch.
I synced my system this morning 2025-05-13T22:00:00Z and after a soft-reboot the issue was gone.
The only way is to wait until the fix propagate to ArchLinux Arm and subsequently to Manjaro Arm unstable.
I also disable all animations. KDE Plasma is gpu heavy and without a gpu (RPI), all its bells and whistles would just bring it down. So yeah, there must be a trade-off. KDE Plasma is the best choice for anybody coming from a windows bacground but it requires a powerful machine unfortunately.
@Sam_Fisher I think you should do a search with “vc4 v3d raspberry” to find out whether or not the raspberry has a gpu and which versions of opengl and vulkan are supported.
Well OK, compared to the Mali gpus inside the Amlogic SOC (odroid devices), we have videocore in our Broadcom SOC (RPI devices). The difference in processing power (in terms of graphics) is probably really big. Amlogic is used in many consumer grade television boxes and mali is used by mediatek and it is in many many smartphones (Even google pixel phones have it). So i think it is safe to say that there is a big difference.
Different hardware for video, 2d, 3d.
Well, geekbench don’t test v3d (gpu for 3d). But let’s install vkmark-git and glmark2-git from AUR. If @nl.smart or @JFL want to compare how weak a pi5 is.
Well, I patched kirigami on x64 to make it not crash …
kirigami got updated today in unstable sync with arch-arm.
Hi,
I agree to launch a test, interesting idea, both package, vkmark-git and glmark2-git, found on AUR ARM.
Do you have some infos, settings to launch those tests ?
https://www.youtube.com/watch?v=QuGcoOJKXT8
dans un autre registre il y aussi ce moment d’anthologie
Just the basic. 2 passes. Wayland for me. v3d for pi. (opengl 3.1 and vulkan 1.4.313)
vulkaninfo (from vulkan-tools)
==========
VULKANINFO
==========
Vulkan Instance Version: 1.4.313
glxinfo (from mesa-utils)
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Broadcom (0x14e4)
Device: V3D 7.1.7.0 (0xffffffff)
Version: 25.0.5
Accelerated: yes
Video memory: 8049MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 3.1
Max compat profile version: 3.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.1
vkmark : 1736 and 1734 (from vkmark-git)
=======================================================
vkmark 2025.01
=======================================================
Vendor ID: 0x14E4
Device ID: 0x55701C33
Device Name: V3D 7.1.7.0
Driver Version: 104857605
Device UUID: 95de9254ccb0d84790557e540b608ed4
glmark2-wayland : 1999 and 2010 (from gl2mark2-git)
=======================================================
glmark2 2023.01
=======================================================
OpenGL Information
GL_VENDOR: Broadcom
GL_RENDERER: V3D 7.1.7.0
GL_VERSION: 3.1 Mesa 25.0.5-arch1.1
Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0
Surface Size: 800x600 windowed
glmark2-es2-wayland : 2007 and 2006 (from gl2mark2-git)
=======================================================
glmark2 2023.01
=======================================================
OpenGL Information
GL_VENDOR: Broadcom
GL_RENDERER: V3D 7.1.7.0
GL_VERSION: OpenGL ES 3.1 Mesa 25.0.5-arch1.1
Surface Config: buf=32 r=8 g=8 b=8 a=8 depth=24 stencil=0 samples=0
Surface Size: 800x600 windowed
vblank_mode=0 glxgears (from mesa-utils)
ATTENTION: default value of option vblank_mode overridden by environment.
8615 frames in 5.0 seconds = 1722.927 FPS
8627 frames in 5.0 seconds = 1725.399 FPS
8632 frames in 5.0 seconds = 1726.365 FPS
8692 frames in 5.0 seconds = 1738.393 FPS
8631 frames in 5.0 seconds = 1726.198 FPS
8623 frames in 5.0 seconds = 1724.349 FPS
8630 frames in 5.0 seconds = 1725.964 FPS
I read that one workaround is to set the animation speed close to 0.
I can’t reproduce this myself, though, as this bug doesn’t affect me.
don’t use kde but fixed with https://bugs.kde.org/show_bug.cgi?id=503703 . kirigami 6.14.1 in unstable. This thread turns into a benchmark for gpu 
Je ne savais pas que tu étais français…
This was fixed with today’s update of kirigami.
De rien.
How to run the installed packages ?
vkmark --help
glmark2 --help
I follow the instructions, but errors appears