Hello @thebearking, I would be really glad to help out the devs and as a fellow dev myself i can see the value of helping the Garuda team in their debugging process. Anyway, back to our points.
I haven’t had an issue for the past two days again, but i do remember the applications that were open and the actions of when this behavior occurred on various occasions so let me add them below:
If i remember more i will add them in a future comment.
A small suspicion I got now that i wrote all of the above is that maybe this could be related with the animation that the windows have. Dragging them and open/close them triggers this nice smooth animation, so maybe its this? Is there a way for me to check it via the logs?
That window animation theory is sharp thinking. Every scenario you listed involves the compositor having to redraw window states while juggling GPU resources.
For sharing your capture:
cd ~/.local/share/kwin-crash-monitor/captures/
tar -czf crash-capture.tar.gz capture-2025-*
curl -F'file=@crash-capture.tar.gz' 0x0.st
Post the URL it gives you.
Want to test if animations are the culprit? Kill them entirely:
Your hybrid setup makes this worse, dragging windows from laptop screen (AMD) to external monitor (NVIDIA) forces frame buffer copies between GPUs. That’s a lot of memory shuffling during an animation that’s already stressing the compositor.
Steam’s the perfect storm here … heavy GPU acceleration plus window state changes. No wonder it’s a consistent trigger.
The capture data should show if we’re getting compositor timing errors before the crash. Keep tracking what you’re doing when it happens.
Just saw your answer, you are a god, thank you for posting the exact commands to execute!
In the meantime, another crash just happened, so i captured this one as well.
This time i had two windows of brave open and just moved them to laptops monitor. Once i inserted a wired Xbox controller the crash happened again. (thats crash no.2 on the report below)
@thebearking this command that disables the animation, didnt seem to be doing something so i just went ahead and disabled the Wobbly Windows from system settings.
Read the README first - it explains the new systemd service setup and the requirement to be in systemd-journal group (needs a full reboot after adding).
Your Xbox controller crashes are interesting - USB device enumeration shouldn’t crash the compositor. That’s a different bug from the animation issues.
Once you have the monitor running, captures go to:
~/.local/share/kwin-crash-monitor/captures/ - Full snapshot
For now, keep sharing via 0x0.st like you did - I’m collecting these links to find patterns. The CSV helps identify crash signatures across users. Once we have enough data showing the same crashes, we can approach KDE devs with solid evidence.
@TNE multiple users seem to be experiencing these crashes and we’re trying to collect data to identify patterns. I’ve been working on a monitoring tool that might help. If you think it’s worth coordinating a community data collection effort and could link the tool or point affected users my way, I’d love to help get to the bottom of this and pass the information upstream to whoever needs it - whether that’s KDE, NVIDIA, Mesa, or Qt depending on what the patterns show. I understand if that is not the play though.
Honestly, the past few days since my latest update last week I didnt have any occurrences.
I closed the window womble animation, had an occurrence a few moments after i closed it, but from that point on i had none!