SUMMARY KDE Wayland suspend fails completely on AMD TeraScale dual GPU hardware (HD 6520G + HD 6630M) resulting in graphics corruption or irrecoverable black screen. Same hardware works perfectly with KDE X11. STEPS TO REPRODUCE 1. Use ASUS N53Ta laptop with AMD A6-3420M APU + dual GPU (HD 6520G integrated + HD 6630M discrete) 2. Boot openSUSE Tumbleweed with radeon driver (amdgpu blacklisted due to conflicts) 3. Login to KDE Plasma Wayland session 4. Execute suspend: systemctl suspend 5. Try to wake system with keyboard/mouse/power button OBSERVED RESULT - Default suspend (deep): Graphics corruption with horizontal lines and visual artifacts - Alternative methods tested (s2idle, freeze): Complete black screen, system totally unresponsive - No recovery possible via Ctrl+Alt+F1-F7, Alt+SysRq, or any other method - Forced reboot required in all cases EXPECTED RESULT System should suspend and resume normally without graphics corruption, as it does when using KDE X11 session on the same hardware. SOFTWARE/OS VERSIONS Linux/KDE Plasma: openSUSE Tumbleweed 20250718 KDE Plasma Version: 6.4.3 KDE Frameworks Version: 6.16.0 Qt Version: 6.9.1 Kernel: 6.15.6-1-default (64-bit) Graphics Platform: Wayland (issue occurs here, X11 works fine) ADDITIONAL INFORMATION Hardware Details: - Manufacturer: ASUSTeK Computer Inc. - Product: N53Ta (2011) - CPU: 4 × AMD A6-3420M APU with Radeon HD Graphics - Memory: 6 GiB RAM (5.3 GiB usable) - GPU 1: AMD SUMO (HD 6520G - TeraScale integrated) - GPU 2: AMD TURKS (HD 6630M - TeraScale discrete) Driver Configuration: - Using radeon driver only (amdgpu blacklisted to avoid conflicts) - lsmod shows: radeon 2101248 45 Power State Information: - /sys/power/state: freeze mem disk - /sys/power/mem_sleep: s2idle [deep] - GPU states: card0=D0 (active), card1=D3cold (suspended) KWin Log Evidence: kwin_wayland_drm: drmSetClientCap for Atomic Mode Setting failed. Using legacy mode on GPU "/dev/dri/card0" Tests Performed: - All suspend methods fail: systemctl suspend, s2idle mode, freeze mode - Various kernel parameters tested (radeon.dmp, ACPI quirks): no effect - systemd suspend hooks and kwin restart scripts: no effect - Runtime power management configurations: no effect Environment Comparison: - KDE X11: Suspend works perfectly on same hardware - GNOME Wayland: Previously worked on same hardware - KDE Wayland: Complete failure with any suspend method Related Hardware: This issue appears specific to AMD TeraScale dual GPU configurations (2011-2012 era). Similar reports found: - Ubuntu Bug #1313804 (HP Pavilion dv6 with same HD 6520G+6630M GPUs) - KDE Bug #454639 (AMD flickering after Wayland suspend) - Multiple openSUSE forum reports of KDE Wayland + AMD suspend issues The hardware is pre-GCN (Graphics Core Next) and kwin_wayland appears to have compatibility issues with TeraScale architecture during suspend/resume operations. Analysis conducted with assistance from Claude AI (Anthropic) including systematic testing and research of similar reported issues.
Thanks for the bug report. Can you get us logs from your system from just before and just after attempting to suspend the system? If you started the wayland session from SDDM, logs are located at ~/.local/share/sddm/wayland-session.log
Hi, Thank you for looking into this issue. I'll provide the requested logs from just before and after the suspend attempt. I've prepared the system to capture fresh logs: - Verified wayland-session.log location exists - Cleared previous logs to get clean capture - Ready to reproduce the issue in controlled manner Steps I'll follow: 1. Fresh login to KDE Wayland session via SDDM 2. Wait a few minutes for normal system activity 3. Attempt suspend with `systemctl suspend` 4. After forced reboot (due to hang), capture the logs 5. Attach wayland-session.log to this bug report I'll reproduce the issue and provide the logs within the next few hours. Best regards, Thiago Canuto
Hi, I've successfully reproduced the suspend issue and collected the requested logs. The wayland-session.log file was empty on my openSUSE system, but I captured comprehensive kwin_wayland logs instead: 1. **Before suspend attempt** (14K): Normal session logs 2. **During suspend attempt** (1.6K): Real-time capture until system hang 3. **After reboot** (9.7K): Post-crash recovery logs The system behaved exactly as described - complete hang requiring forced reboot after suspend attempt. I'm attaching all three log files which should show the exact moment of failure. Best regards, Thiago Canuto
Created attachment 183671 [details] KWin Wayland logs: before suspend attempt
Created attachment 183672 [details] KWin Wayland logs: during suspend attempt
Created attachment 183673 [details] KWin Wayland logs after suspend attempt
*** Bug 507680 has been marked as a duplicate of this bug. ***
Thanks for the logs. I'll let the kwin developers take a closer look.