Created attachment 186150 [details] Sleep and log in cycle where this happens SUMMARY When waking from deep sleep (suspend to ram), most times the display turns on to a black/blank screen. Pressing any key on the keyboard will then show the login screen as expected. This seems to me to be some sort of race condition, maybe between dGPU and iGPU, but I'm not smart enough to understand my logs completely STEPS TO REPRODUCE 1. Suspend to ram 2. Wake PC 3. Do not press anything OBSERVED RESULT A blank/black screen, clearly backlit but not updating to show login screen EXPECTED RESULT The login screen ready for input SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.5.0 KDE Frameworks Version: 6.19.0 Qt Version: 6.10.0 Kernel Version: 6.17.5-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 9800X3D 8-Core Processor Memory: 64 GiB of RAM (60.5 GiB usable) Graphics Processor 1: NVIDIA GeForce RTX 5090/PCIe/SSE2 Graphics Processor 2: NVIDIA GeForce RTX 5090/PCIe/SSE2 ADDITIONAL INFORMATION First noticed this in 6.4.5. Was not always like this. Logs attached of a sleep+login cycle
Created attachment 186270 [details] logs from a good wake, no black screen By happenstance, when waking my PC today it did not have a black screen. This happens maybe 10% of the time. I included the logs from when suspend started up until after the wake when I grabbed the logs.
Here are the portions of the logs that look important. There are errors related to kwin_wayland. System returned from suspend here: Oct 25 15:47:14 desktop systemd-sleep[10048]: System returned from sleep operation 'suspend'. Oct 25 15:47:14 desktop kernel: Freezing user space processes completed (elapsed 0.001 seconds) This looks like kwin had problems contacting one video card: Oct 25 15:47:14 desktop kernel: Restarting tasks: Starting Oct 25 15:47:14 desktop kernel: pci_bus 0000:06: Allocating resources Oct 25 15:47:14 desktop kernel: Restarting tasks: Done Oct 25 15:47:14 desktop kernel: random: crng reseeded on system resumption Oct 25 15:47:14 desktop kernel: PM: suspend exit Oct 25 15:47:14 desktop kwin_wayland[986]: Failed to open drm node: "/dev/dri/card0" Oct 25 15:47:14 desktop kwin_wayland[986]: Failed to open drm node: "/dev/dri/card0" Target suspend stopped here: Oct 25 15:47:15 desktop systemd[1]: Stopped target Sleep. Oct 25 15:47:15 desktop systemd[1]: Reached target Suspend.. Oct 25 15:47:15 desktop systemd[1]: Starting NVIDIA system resume actions... Oct 25 15:47:15 desktop systemd[1]: Stopped target Suspend. And then kwin logged further errors: Oct 25 15:47:15 desktop kwin_wayland[986]: Atomic modeset test failed! Permission denied Oct 25 15:47:15 desktop kwin_wayland[986]: Setting dpms mode failed! Oct 25 15:47:15 desktop kwin_wayland[986]: Atomic modeset test failed! Permission denied Oct 25 15:47:15 desktop kwin_wayland[986]: Setting dpms mode failed! Oct 25 15:47:15 desktop kwin_wayland[986]: Atomic modeset test failed! Permission denied Oct 25 15:47:15 desktop kwin_wayland[986]: Setting dpms mode failed! Oct 25 15:47:15 desktop kwin_wayland[986]: Atomic modeset test failed! Permission denied Oct 25 15:47:15 desktop kwin_wayland[986]: Setting dpms mode failed! Oct 25 15:47:15 desktop suspend[10129]: nvidia-resume.service Oct 25 15:47:15 desktop logger[10129]: <13>Oct 25 15:47:15 suspend: nvidia-resume.service Oct 25 15:47:15 desktop systemd[1]: nvidia-resume.service: Deactivated successfully. Oct 25 15:47:15 desktop systemd[1]: Finished NVIDIA system resume actions. Oct 25 15:47:15 desktop kwin_wayland[986]: Atomic modeset test failed! Permission denied Oct 25 15:47:15 desktop kwin_wayland[986]: Applying output configuration failed!
I'm seeing the same issue on nvidia driver 580.105.08 (open kernel modules)
I'm seeing something similar on a desktop with a single AMD GPU (so, no iGPU involved; and no suspend either, only DPMS). So far, I've seen it happen both on screen power off (the lockscreen will dim and freeze, but the screen stays on) and power on (the screen wakes up to a black screen, and I need to VT switch [I don't recall if a simpler keyboard input helps; but a VT switch definitely does the trick]). It does not happen on every lockscreen timeout. On my end, it started occurring *right* after an update to 6.5.4 (upgrading from 6.5.3, same boot session, *full* log-out/log-in (as in, back to the linux vt & getty, I don't use any GUI greeters). I'm seeing the same spam of kwin_wayland_drm: Atomic modeset test failed! Invalid argument kwin_wayland_drm: Setting dpms mode failed! in the logs around the screen off/screen on timestamps. (Note that I'm *also* seeing a few 'Atomic modeset test failed' in the logs even when things work fine...)
*** This bug has been marked as a duplicate of bug 513151 ***
Created attachment 187569 [details] Logs from a bad wake, black screen, even after update Unfortunately, still facing the same issue that this ticket was opened for, though admittedly it isn't a show stopping bug. To summarize again the issue: when waking from sleep, the PC shows a black, but backlit, screen. Log in screen not shown and cannot enter password. Upon pressing any key, the PC finally fully wakes up, showing all screens as expected, and I can now enter my password. Added additional log file after the update, including logs from before sleep to after log in Thank you for your time!
(In reply to anthonyjbarricelli from comment #6) > Unfortunately, still facing the same issue that this ticket was opened for, > though admittedly it isn't a show stopping bug. What version of Plasma do you have installed? This should be fixed with 6.5.5, as you can see in bug 513151 (that this was marked a duplicate of). Relevant log lines show the same error as before and as with bug 513151 Dec 12 22:22:08 desktop org_kde_powerdevil[1218]: [ 1378] Udev event detected Dec 12 22:22:08 desktop kwin_wayland[1008]: Atomic modeset test failed! Permission denied Dec 12 22:22:08 desktop discord[1652]: 22:22:08.942 › [GatewaySocket] Connection has reset backoff for reason: power monitor resumed Dec 12 22:22:08 desktop kwin_wayland[1008]: Setting dpms mode failed! Dec 12 22:22:08 desktop discord[1652]: 22:22:08.942 › [GatewaySocket] Setting connection state to CONNECTING Dec 12 22:22:08 desktop discord[1652]: 22:22:08.942 › [GatewaySocket] [CONNECT] wss://gateway.discord.gg, encoding: etf, version: 9, compression: zstd-stream Dec 12 22:22:08 desktop kwin_wayland[1008]: Atomic modeset test failed! Permission denied Dec 12 22:22:08 desktop kwin_wayland[1008]: Setting dpms mode failed! Dec 12 22:22:08 desktop kwin_wayland[1008]: Atomic modeset test failed! Permission denied Dec 12 22:22:08 desktop kwin_wayland[1008]: Setting dpms mode failed! Dec 12 22:22:08 desktop kwin_wayland[1008]: Atomic modeset test failed! Permission denied Dec 12 22:22:08 desktop kwin_wayland[1008]: Setting dpms mode failed!
(In reply to TraceyC from comment #7) > (In reply to anthonyjbarricelli from comment #6) > > Unfortunately, still facing the same issue that this ticket was opened for, > > though admittedly it isn't a show stopping bug. > > What version of Plasma do you have installed? This should be fixed with > 6.5.5, as you can see in bug 513151 (that this was marked a duplicate of). > > Relevant log lines show the same error as before and as with bug 513151 Hi Tracey, According to this comment https://bugs.kde.org/show_bug.cgi?id=513151#c28 (along with the one above it), it seems that the change to kwin should have been backported? I am on kwin 6.5.4-3, here is the commit in the Arch package repo https://gitlab.archlinux.org/archlinux/packaging/packages/kwin/-/commit/dbd9f99bfee65bdaaabcc488610ee6d15ded2c19. The commit hash in the file (ef450432) seems to match the one in the comment by Zamundaaa. All to say I believe I am on the patched version of kwin which should have the fix in place, although I am currently on Plasma 6.5.4
Thanks for clarifying. I'll let the kwin developers investigate further.
I can't think of anything on the KWin side that would cause this. Maybe the lockscreen just isn't rendering until it gets some keyboard input? If you use the mouse, does anything show up then, even if it's just the cursor?
(In reply to Zamundaaa from comment #10) > I can't think of anything on the KWin side that would cause this. Maybe the > lockscreen just isn't rendering until it gets some keyboard input? > If you use the mouse, does anything show up then, even if it's just the > cursor? I don't know how I haven't realized sooner, but moving the mouse does in fact turn the screen from black to displaying the lockscreen. My keyboard and mouse are plugged in via a KVM switch, I wonder if that could cause issues?
Unlikely. Your original log has a few of this in it: > Could not create EGL surface (EGL error 0x3003) Does that appear when you trigger the problem again?
Created attachment 188339 [details] Wake to black screen. Use mouse to fully wake (In reply to Zamundaaa from comment #12) > Unlikely. Your original log has a few of this in it: > > Could not create EGL surface (EGL error 0x3003) > Does that appear when you trigger the problem again? Yes it does. I attached a new log and closed a lot of programs so hopefully it is less noisy. This time I made the lockscreen appear with the mouse in the off chance that changes anything. Thank you for looking.
Okay, then that's suspicious at least. The error code is EGL_BAD_ALLOC, so that leading to the lockscreen not showing anything wouldn't be surprising. I have no clue what would be causing that error though.
Created attachment 188377 [details] good wake after patch (In reply to Zamundaaa from comment #14) > Okay, then that's suspicious at least. The error code is EGL_BAD_ALLOC, so > that leading to the lockscreen not showing anything wouldn't be surprising. > I have no clue what would be causing that error though. I've added one more log file as it might be another hint should anyone need. This time the computer woke just fine. There were _no_ "Atomic modeset test failed" messages. There were, however, more of the "Could not create EGL surface (EGL error 0x3003)" messages. So while also maybe a bug, I don't think it is causing the behavior I'm usually seeing on the bad wake cycles. Thank you!
*** Bug 514641 has been marked as a duplicate of this bug. ***
I am on AMD GPU (Strix Halo) and also see this problem even in 6.5.5. After resuming from suspend very often screen is frozen. I can reset it by only killing `kwin_wayland` process via ssh. But again, some resumes happen fine, and the screen is working as expected.
(In reply to Yahor Berdnikau from comment #17) > I am on AMD GPU (Strix Halo) and also see this problem even in 6.5.5. After > resuming from suspend very often screen is frozen. I can reset it by only > killing `kwin_wayland` process via ssh. But again, some resumes happen fine, > and the screen is working as expected. That actually sounds like a different kind of bug. More serious than this one which just seems to be that the screen initializes incorrectly upon wake, and is fixed by just moving the mouse or pressing the keyboard. I would take a look at bug 514641 which, in my opinion, was incorrectly marked as a duplicate of this bug. Maybe it is similar to what you're seeing?
> I would take a look at bug 514641 which, in my opinion, was incorrectly marked as a duplicate of this bug. Maybe it is similar to what you're > seeing? It doesn't look related as it is about cold boot and I don't have any problems with cold boot. Only suspend/resume cycle. And in the logs, I see kwin_wayland_drm: Atomic modeset test failed! Permission denied kwin_wayland_drm: Setting dpms mode failed! which relate more to the messages posted in this bug.
Maybe my problem is related more to https://bugs.kde.org/show_bug.cgi?id=513151
I created a separate bug from my problem: https://bugs.kde.org/show_bug.cgi?id=514728