And apologies for the second message but some other things I thought of:

* I already am doing the "preserve video memory after suspend" referenced https://wiki.archlinux.org/title/NVIDIA/Tips_and_tricks#Preserve_video_memory_after_suspend
* I already use the modesetting driver referenced at https://community.kde.org/Plasma/Wayland/Nvidia, and I also use `fbdev=1`

(In reply to etnguyen03+kdebugs from comment #1)
> And apologies for the second message but some other things I thought of:
> 
> * I already am doing the "preserve video memory after suspend" referenced
> https://wiki.archlinux.org/title/NVIDIA/
> Tips_and_tricks#Preserve_video_memory_after_suspend
> * I already use the modesetting driver referenced at
> https://community.kde.org/Plasma/Wayland/Nvidia, and I also use `fbdev=1`

Would you be able to post complete logs when you trigger this?

Did you also enable nvidia-suspend.service? If so you should see something in the journal on that.

Did this start happening after a recent update? Which version of the nvidia drivers are you on?

Thanks!

Created attachment 163629 [details]
System journal logs

(In reply to fanzhuyifan from comment #2)
> Would you be able to post complete logs when you trigger this?

Attaching.

> Did you also enable nvidia-suspend.service? If so you should see something
> in the journal on that.

Yes, and I see logs:

```
systemd[1]: Starting NVIDIA system suspend actions...
░░ Subject: A start job for unit nvidia-suspend.service has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit nvidia-suspend.service has begun execution.
░░ 
░░ The job identifier is 2476.
suspend[3794]: nvidia-suspend.service
logger[3794]: <13>Nov 29 20:48:28 suspend: nvidia-suspend.service
systemd[1]: nvidia-suspend.service: Deactivated successfully.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ The unit nvidia-suspend.service has successfully entered the 'dead' state.
systemd[1]: Finished NVIDIA system suspend actions.
░░ Subject: A start job for unit nvidia-suspend.service has finished successfully
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit nvidia-suspend.service has finished successfully.
░░ 
░░ The job identifier is 2476.
```

> Did this start happening after a recent update? Which version of the nvidia
> drivers are you on?

So I recently upgraded my hardware (but did not upgrade my GPU), and as part of that I reinstalled my OS + KDE and switched to Wayland. I think this has more to do with my switch to Wayland (I can try Xorg if that's useful). Before switching to Wayland, suspend worked completely fine.

I am on nvidia 545.29.06-2.

Please put
> QT_LOGGING_RULES="kwin_wayland_*.debug=true"
into /etc/environment, reboot, and then test this again and attach the KWin log afterwards. You can get that (filtered to only KWin) with
> journalctl --user-unit plasma-kwin_wayland --boot 0

If you could record a drm debug log as described in https://invent.kde.org/plasma/kwin/-/wikis/Debugging-DRM-issues that could also be useful.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!

*** Bug 451386 has been marked as a duplicate of this bug. ***

*** Bug 437808 has been marked as a duplicate of this bug. ***

Hi - sorry for the late response, I was away for a few weeks. On kwin 5.27.10-2, I have noticed that this happens less often -- or sometimes something slightly different happens (I can unlock my session fine, but then one of my monitors, and every window that I drag into it more than 50%, appears black or does not update).

Logs of this are attached.

Created attachment 165083 [details]
kwin logs 2024-01-20

Created attachment 165084 [details]
DRM debug logs 2024-01-20

*** This bug has been marked as a duplicate of bug 475605 ***

Not a duplicate of that issue, my mistake. That's X11-only and this is on Wayland.

It seems that on KDE6 there is no such problem on Wayland with Nvidia drivers.
I just made that image https://disk.yandex.ru/d/QgccYm1t71gLWw
I downloaded it to my computer in livecd mode.

Operating System: ROSA Fresh Desktop 2023.1
KDE Plasma Version: 5.93.0
KDE Frameworks Version: 5.249.0
Qt Version: 6.7.0
Kernel Version: 6.7.4-generic-2rosa2023.1-x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-7700K CPU @ 4.20GHz
Memory: 15.5 ГиБ of RAM
Graphics Processor: NVIDIA GeForce RTX 3050/PCIe/SSE2
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: B250M-D3H

I assembled the kernel according to this recommendation 
https://community.kde.org/Distributions/Packaging_Recommendations#Kernel_configuration

I put the computer into standby mode several times and after exiting standby 
mode there were no problems with the operation of the Nvidia driver.

(In reply to Victor Ryzhykh from comment #15)
> It seems that on KDE6 there is no such problem on Wayland with Nvidia
> drivers.
> I just made that image https://disk.yandex.ru/d/QgccYm1t71gLWw
> I downloaded it to my computer in livecd mode.
> 
> Operating System: ROSA Fresh Desktop 2023.1
> KDE Plasma Version: 5.93.0
> KDE Frameworks Version: 5.249.0
> Qt Version: 6.7.0
> Kernel Version: 6.7.4-generic-2rosa2023.1-x86_64 (64-bit)
> Graphics Platform: Wayland
> Processors: 8 × Intel® Core™ i7-7700K CPU @ 4.20GHz
> Memory: 15.5 ГиБ of RAM
> Graphics Processor: NVIDIA GeForce RTX 3050/PCIe/SSE2
> Manufacturer: Gigabyte Technology Co., Ltd.
> Product Name: B250M-D3H
> 
> I assembled the kernel according to this recommendation 
> https://community.kde.org/Distributions/
> Packaging_Recommendations#Kernel_configuration
> 
> I put the computer into standby mode several times and after exiting standby 
> mode there were no problems with the operation of the Nvidia driver.

What Nvidia driver version are you using? After suspending and resuming, could you check the output of "cat /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us"?

(In reply to fanzhuyifan from comment #16)
> What Nvidia driver version are you using? After suspending and resuming,
> could you check the output of "cat
> /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us"?
Nvidia 545 driver is used.
I made a disk image to test the functionality of Wayland on my desktop computer.
I specifically provided a link to the disk image so that others could also test how Wayland works on Nvidia.
I can't install KDE6 on my desktop computer until program Lokalize is ported to kf6.
I have KDE5 running on my desktop computer.
I have KDE6 installed on my ASUS ROG Zephyrus M16 (GU603HE-K8007) laptop.
But it has hybrid graphics, so there is no such possibility for verification.
On a laptop with KDE 6, it works well on X11 and Wayland.
I hope that someone will be able to check Wayland’s work on NVIDIA, using the image of the disk that I applied above.

(In reply to Victor Ryzhykh from comment #17)
> (In reply to fanzhuyifan from comment #16)
> > What Nvidia driver version are you using? After suspending and resuming,
> > could you check the output of "cat
> > /sys/devices/system/cpu/cpuidle/low_power_idle_system_residency_us"?
> Nvidia 545 driver is used.
> I made a disk image to test the functionality of Wayland on my desktop
> computer.
> I specifically provided a link to the disk image so that others could also
> test how Wayland works on Nvidia.
> I can't install KDE6 on my desktop computer until program Lokalize is ported
> to kf6.
> I have KDE5 running on my desktop computer.
> I have KDE6 installed on my ASUS ROG Zephyrus M16 (GU603HE-K8007) laptop.
> But it has hybrid graphics, so there is no such possibility for verification.
> On a laptop with KDE 6, it works well on X11 and Wayland.
> I hope that someone will be able to check Wayland’s work on NVIDIA, using
> the image of the disk that I applied above.

Could you paste the output of `journalctl -b` and `sudo dmesg` on the reported working system with plasma 6 and nvidia? Just wanted to check which suspend level the system entered.

(In reply to Victor Ryzhykh from comment #17)
> Nvidia 545 driver is used.
There is a file in the nvidia driver
/etc/modprobe.d/nvidia-power-management.conf
with text


# The destination should not be using tmpfs, so we prefer
# /var/tmp instead of /tmp
options nvidia NVreg_PreserveVideoMemoryAllocations=1 NVreg_TemporaryFilePath=/var/tmp

Created attachment 165925 [details]
journalctl -b

(In reply to fanzhuyifan from comment #18)
> Could you paste the output of `journalctl -b` 
Done.

Created attachment 165926 [details]
sudo dmesg

(In reply to fanzhuyifan from comment #18)
>  and `sudo dmesg` on the
> reported working system with plasma 6 and nvidia? Just wanted to check which
> suspend level the system entered.
Done.

(In reply to fanzhuyifan from comment #18)
> Could you paste the output of `journalctl -b` and `sudo dmesg` on the
> reported working system with plasma 6 and nvidia? Just wanted to check which
> suspend level the system entered.
Did you manage to see anything useful?

Build version 6.0.0.

Operating System: ROSA Fresh Desktop 2023.1
KDE Plasma Version: 6.0.0
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.7.6-generic-1rosa2023.1-x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-7700K CPU @ 4.20GHz
Memory: 15.5 ГиБ of RAM
Graphics Processor: NVIDIA GeForce RTX 3050/PCIe/SSE2
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: B250M-D3H

When idle, the computer goes into sleep mode, as configured in the energy saving settings. All previously running applications continue to run after waking up.

(In reply to Victor Ryzhykh from comment #23)
> When idle, the computer goes into sleep mode, as configured in the energy
> saving settings. All previously running applications continue to run after
> waking up.
The nvidia driver is compiled using the following configs

Created attachment 166095 [details]
Nvidia build config

(In reply to Victor Ryzhykh from comment #23)
> When idle, the computer goes into sleep mode, as configured in the energy
> saving settings. All previously running applications continue to run after
> waking up.

The nvidia driver is compiled using the following configs

But if we talk about kde6, it is very good. Today this is the best of the kde6 for me. Working on kde6 is very convenient. It’s a shame that I have to go back to kde5. I hope this doesn't last very long.
P.S.
In the distribution, the main one is KDE5, and I cannot compile them so that they can be installed simultaneously with KDE6.

(In reply to Victor Ryzhykh from comment #26)
> But if we talk about kde6, it is very good. Today this is the best of the
> kde6 for me. Working on kde6 is very convenient. It’s a shame that I have to
> go back to kde5. I hope this doesn't last very long.
> P.S.
> In the distribution, the main one is KDE5, and I cannot compile them so that
> they can be installed simultaneously with KDE6.

I'm sorry. Accidentally wrote in the wrong bar.

Same issue. It happens any time going idle, or closing laptop lid.

Operating System: Arch Linux 
KDE Plasma Version: 6.0.1
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.7.9-arch1-1 (64-bit)
Graphics Platform: X11
Processors: 8 × AMD Ryzen 7 3700U with Radeon Vega Mobile Gfx
Memory: 13.5 GiB of RAM
Graphics Processor: AMD Radeon Vega 10 Graphics
Manufacturer: LENOVO
Product Name: 20NF0018US
System Version: ThinkPad E595

Created attachment 167311 [details]
dmesg logs

Not sure, if this is related, but after hibernate and waking up, I see so much glichtes and artefacts, that the desktop gets unusable such that I have to restart the desktop.
Distribution: KDE Neon
Desktop: KDE Plasma 6.0.2
Qt Version: 6.6.2
Graphics Platform: Wayland
Graphics Card: NVIDIA GTX 1060 
NVIDIA Driver Version: 535.161.07

Created attachment 167312 [details]
journcal ctl logs

Created attachment 167313 [details]
glitches

(In reply to Victor Ryzhykh from comment #17)
> Nvidia 545 driver is used.
When I used drivers 545, I had no crashes after exiting sleep mode, but after switching to drivers 550, problems appeared. Although it is possible that the transition to new drivers simply coincided with some other change.

(In reply to Victor Ryzhykh from comment #32)
> (In reply to Victor Ryzhykh from comment #17)
> > Nvidia 545 driver is used.
> When I used drivers 545, I had no crashes after exiting sleep mode, but
> after switching to drivers 550, problems appeared. Although it is possible
> that the transition to new drivers simply coincided with some other change.

Operating System: ROSA Fresh Desktop 2023.1
KDE Plasma Version: 6.0.3
KDE Frameworks Version: 6.0.0
Qt Version: 6.6.2
Kernel Version: 6.8.2-generic-1rosa2023.1-x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-7700K CPU @ 4.20GHz
Memory: 15.5 ГиБ of RAM
Graphics Processor: NVIDIA GeForce RTX 3050/PCIe/SSE2
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: B250M-D3H

(In reply to Victor Ryzhykh from comment #32)
> When I used drivers 545, I had no crashes after exiting sleep mode, but
> after switching to drivers 550, problems appeared. Although it is possible
> that the transition to new drivers simply coincided with some other change.

Oops. I have now reinstalled the system.
The system exits sleep mode on the 550 drivers, on wayland, without errors.
Apparently the old system had accumulated errors from constant testing of different versions of the compiled packages for KDE6.

I am also experiencing a version of this bug, after wakeup there are parts of the screen flickering, certain apps (like the system monitor) have 90% of text missing.

KDE 6.0.4
Wayland
NVIDIA GeForce RTX 3080 550.78 drivers

Hello, I am also experiencing the graphical glitches after resume from suspend. plasmashell --replace is mandatory to get the system working again.

KDE 6.0.4
Nvidia GTX 1050 Ti 555.42.2 drivers but noticed this bug in the stable version of the driver 550.78 too!
Wayland

Can also sometimes reproduce on AMDGPU, so it seems not NVIDIA only.

(In reply to Fushan Wen from comment #37)
> Can also sometimes reproduce on AMDGPU, so it seems not NVIDIA only.

Me too on Fedora 40, Plasma 6.0.5, Wayland.

Something similar happened to me this morning. Fedora 40, Plasma 6.0.5, RX580 GPU. Screen didn't go black, but the lock screen was completely frozen when waking from sleep. I could move the mouse, but the clock didn't change, and Ctrl-Alt-F1 brought up a blinking cursor that wouldn't take any keyboard input. Had to hard reboot.

Forgot how to get logs this time but if it happens again I'll try and collect them.

Unsure if this is related but this morning I was unable to sign into a Wayland session (I could see an SDDM on Wayland, change to Plasma on Xorg, and use Xorg which I am using now though), I see this in logs:

> Jun 08 07:28:24 Ethan-PC kwin_wayland[1580]: kwin_wayland_drm: Atomic modeset test failed! Invalid argument
> Jun 08 07:28:24 Ethan-PC kwin_wayland[1580]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated. <image> and <target> are incompatible
> Jun 08 07:28:24 Ethan-PC kwin_wayland[1580]: kwin_scene_opengl: Invalid framebuffer status:  "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
> Jun 08 07:28:24 Ethan-PC kwin_wayland[1580]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated. <image> and <target> are incompatible
> Jun 08 07:28:24 Ethan-PC kwin_wayland[1580]: kwin_scene_opengl: Invalid framebuffer status:  "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
> Jun 08 07:28:24 Ethan-PC kwin_wayland[1580]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated. <image> and <target> are incompatible
> Jun 08 07:28:24 Ethan-PC kwin_wayland[1580]: kwin_scene_opengl: Invalid framebuffer status:  "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
> Jun 08 07:28:24 Ethan-PC kwin_wayland[1580]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated. <image> and <target> are incompatible
> Jun 08 07:28:24 Ethan-PC kwin_wayland[1580]: kwin_scene_opengl: Invalid framebuffer status:  "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"

(In reply to Ethan Nguyen from comment #40)
> Unsure if this is related but this morning I was unable to sign into a
> Wayland session (I could see an SDDM on Wayland, change to Plasma on Xorg,
> and use Xorg which I am using now though), I see this in logs:
> 
> > Jun 08 07:28:24 Ethan-PC kwin_wayland[1580]: kwin_wayland_drm: Atomic modeset test failed! Invalid argument
> > Jun 08 07:28:24 Ethan-PC kwin_wayland[1580]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated. <image> and <target> are incompatible
> > Jun 08 07:28:24 Ethan-PC kwin_wayland[1580]: kwin_scene_opengl: Invalid framebuffer status:  "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
> > Jun 08 07:28:24 Ethan-PC kwin_wayland[1580]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated. <image> and <target> are incompatible
> > Jun 08 07:28:24 Ethan-PC kwin_wayland[1580]: kwin_scene_opengl: Invalid framebuffer status:  "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
> > Jun 08 07:28:24 Ethan-PC kwin_wayland[1580]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated. <image> and <target> are incompatible
> > Jun 08 07:28:24 Ethan-PC kwin_wayland[1580]: kwin_scene_opengl: Invalid framebuffer status:  "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"
> > Jun 08 07:28:24 Ethan-PC kwin_wayland[1580]: kwin_scene_opengl: 0x502: GL_INVALID_OPERATION error generated. <image> and <target> are incompatible
> > Jun 08 07:28:24 Ethan-PC kwin_wayland[1580]: kwin_scene_opengl: Invalid framebuffer status:  "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"

I have a similar issue, I created another bug report for it: https://bugs.kde.org/show_bug.cgi?id=488941

I have a similar problem, but it happens on boot.
Plasma 6.1.1
Archlinux
Nvidia proprietary driver 555
Rtx 3060 ti

Similar here: 
After I suspend to RAM and resume, my KDE setup (Wayland OR X11), AMG-GPU on Manjaro) leaves me with a black screen and a working cursor that changes when I hover over a textbox (but I can't see the textbox) on the lockscreen.
Furthermore, I see [Bug 483163)[https://bugs.kde.org/show_bug.cgi?id=483163] related to this problem.

Created attachment 171813 [details]
Recorded the transition into sleep mode

After updating egl-wayland to version 1.1.14, on Nvidia driver 555.58.02,
exiting sleep mode occurs without failure and a black screen.
Tested with screen lock enabled and with screen lock disabled.
Everything works flawlessly.
Recorded the transition into sleep mode and exit from it
with the completion of recording.

#-----------------------------------------------------------

Operating System: ROSA Fresh Desktop 2023.1
KDE Plasma Version: 6.1.3
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.2
Kernel Version: 6.10.0-generic-1rosa2023.1-x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-7700K CPU @ 4.20GHz
Memory: 15.5 ГиБ of RAM
Graphics Processor: NVIDIA GeForce RTX 3050/PCIe/SSE2
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: B250M-D3H

#------------------------------------------------------------

GBM platform:
EGL API version: 1.5
EGL vendor string: NVIDIA
EGL version string: 1.5
EGL client APIs: OpenGL_ES OpenGL
EGL extensions string:
    EGL_ANDROID_native_fence_sync, EGL_EXT_buffer_age, EGL_EXT_client_sync,
    EGL_EXT_create_context_robustness, EGL_EXT_image_dma_buf_import,
    EGL_EXT_image_dma_buf_import_modifiers, EGL_EXT_output_base,
    EGL_EXT_output_drm, EGL_EXT_present_opaque, EGL_EXT_protected_content,
    EGL_EXT_stream_acquire_mode, EGL_EXT_stream_consumer_egloutput,
    EGL_EXT_sync_reuse, EGL_IMG_context_priority, EGL_KHR_config_attribs,
    EGL_KHR_context_flush_control, EGL_KHR_create_context,
    EGL_KHR_create_context_no_error, EGL_KHR_fence_sync,
    EGL_KHR_get_all_proc_addresses, EGL_KHR_gl_colorspace,
    EGL_KHR_gl_renderbuffer_image, EGL_KHR_gl_texture_2D_image,
    EGL_KHR_gl_texture_3D_image, EGL_KHR_gl_texture_cubemap_image,
    EGL_KHR_image, EGL_KHR_image_base, EGL_KHR_no_config_context,
    EGL_KHR_partial_update, EGL_KHR_reusable_sync, EGL_KHR_stream,
    EGL_KHR_stream_attrib, EGL_KHR_stream_consumer_gltexture,
    EGL_KHR_stream_cross_process_fd, EGL_KHR_stream_fifo,
    EGL_KHR_stream_producer_eglsurface, EGL_KHR_surfaceless_context,
    EGL_KHR_swap_buffers_with_damage, EGL_KHR_wait_sync,
    EGL_MESA_image_dma_buf_export, EGL_NV_nvrm_fence_sync,
    EGL_NV_output_drm_flip_event, EGL_NV_quadruple_buffer,
    EGL_NV_robustness_video_memory_purge, EGL_NV_stream_attrib,
    EGL_NV_stream_consumer_eglimage, EGL_NV_stream_consumer_gltexture_yuv,
    EGL_NV_stream_cross_display, EGL_NV_stream_cross_object,
    EGL_NV_stream_cross_process, EGL_NV_stream_cross_system,
    EGL_NV_stream_dma, EGL_NV_stream_fifo_next,
    EGL_NV_stream_fifo_synchronous, EGL_NV_stream_flush,
    EGL_NV_stream_metadata, EGL_NV_stream_origin, EGL_NV_stream_remote,
    EGL_NV_stream_reset, EGL_NV_stream_socket, EGL_NV_stream_socket_inet,
    EGL_NV_stream_socket_unix, EGL_NV_stream_sync, EGL_NV_system_time,
    EGL_NV_triple_buffer, EGL_WL_bind_wayland_display,
    EGL_WL_wayland_eglstream
OpenGL core profile vendor: NVIDIA Corporation
OpenGL core profile renderer: NVIDIA GeForce RTX 3050/PCIe/SSE2
OpenGL core profile version: 4.6.0 NVIDIA 555.58.02
OpenGL core profile shading language version: 4.60 NVIDIA
OpenGL core profile extensions:

Created attachment 171814 [details]
Sleep

I made a screen recording in mp4.
The previous recording in webm format skips frames,
so it's very dull.

(In reply to Victor Ryzhykh from comment #44)
> After updating egl-wayland to version 1.1.14, on Nvidia driver 555.58.02,
> exiting sleep mode occurs without failure and a black screen.
> Tested with screen lock enabled and with screen lock disabled.
> Everything works flawlessly.

I also checked the operation of KDE5 on egl-wayland version 1.1.14
on the Nvidia driver 555.58.02, switching to standby mode with and
without a screen lock. There are no problems with the image on the
screen after waking up from sleep mode.

# -------------------------------------------------

Operating System: ROSA Fresh Desktop 2023.1
KDE Plasma Version: 5.27.11
KDE Frameworks Version: 5.116.0
Qt Version: 5.15.14
Kernel Version: 6.10.0-generic-1rosa2023.1-x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 8 × Intel® Core™ i7-7700K CPU @ 4.20GHz
Memory: 15.5 ГиБ of RAM
Graphics Processor: NVIDIA GeForce RTX 3050/PCIe/SSE2
Manufacturer: Gigabyte Technology Co., Ltd.
Product Name: B250M-D3H

#---------------------------------------------------

A sample of computer hardware was loaded into the database. Thank you!

Probe URL: https://linux-hardware.org/?probe=2d6613a8a6

I was able to find a work around and made an alias for it.
```bash
killall kwin_wayland &&  killall kwin_wayland_wrapper && startplasma-wayland
```
This seems to restart the session and allow me to get back into kde without having to reboot the entire system.(In reply to Ethan Nguyen from comment #0)
> SUMMARY
> After I suspend to RAM and resume, my KDE setup (Wayland, Nvidia 1060, using
> the nvidia driver, on Arch Linux) leaves me with a black screen and a
> working cursor that changes when I hover over a textbox (but I can't see the
> textbox) on the lockscreen.
> 
> I see this in the system journal right after I resume from RAM:
> 
> ```
> kwin_wayland[1399]: kwin_wayland_drm: Atomic commit failed! Permission denied
> kwin_wayland[1399]: kwin_wayland_drm: Presentation failed! Permission denied
> kwin_wayland[1399]: kwin_wayland_drm: Atomic commit failed! Permission denied
> kwin_wayland[1399]: kwin_wayland_drm: Presentation failed! Permission denied
> kwin_wayland[1399]: kwin_wayland_drm: Atomic modeset commit failed!
> Permission denied
> kwin_wayland[1399]: kwin_wayland_drm: Setting dpms mode failed!
> kwin_wayland[1399]: kwin_wayland_drm: Atomic modeset commit failed!
> Permission denied
> kwin_wayland[1399]: kwin_wayland_drm: Setting dpms mode failed!
> kwin_wayland[1399]: kwin_core: Could not find window with uuid
> "{38667f04-f9ad-4cc3-958b-f8d804def467}"
> kwin_wayland[1399]: kwin_core: Could not find window with uuid
> "{38667f04-f9ad-4cc3-958b-f8d804def467}"
> kwin_wayland[1399]: kwin_core: Could not find window with uuid
> "{38667f04-f9ad-4cc3-958b-f8d804def467}"
> kwin_wayland[1399]: kwin_core: Could not find window with uuid
> "{38667f04-f9ad-4cc3-958b-f8d804def467}"
> ```
> 
> and then lots of these lines, filling up my journal until I reboot
> 
> ```
> kwin_core: Applying KScreen config failed!
> ```
> 
> I can't seem to find a way to recover from this other than to reboot, which
> is, of course, extremely disruptive.
> 
> STEPS TO REPRODUCE
> 1. Put the computer to sleep (i.e. suspend to RAM)
> 2. Wake it back up
> 
> OBSERVED RESULT
> Black screen -- no lock screen displayed, but I can still move my mouse
> cursor around and see it respond to the presence of a text box
> 
> EXPECTED RESULT
> I should be able to see my lock screen.
> 
> SOFTWARE/OS VERSIONS
> Linux/KDE Plasma: Arch Linux, latest packages
> (available in About System)
> KDE Plasma Version: 5.27.9
> KDE Frameworks Version: 5.112.0
> Qt Version: 5.15.11
> 
> ADDITIONAL INFORMATION
> My hardware (Nvidia 1060, nvidia proprietary driver) is probably relevant?
> Not quite sure how to attach bugtraces, but I can if needed. Thank you!

I was able to find a work around and made an alias for it.
killall kwin_wayland &&  killall kwin_wayland_wrapper && startplasma-wayland
This seems to restart the session and allow me to get back into kde without having to reboot the entire system. As previously mentioned, just make an alias for it and you can run this command in a seperate tty. Let me know if this workaround helps.

(In reply to Victor Ryzhykh from comment #44)
> After updating egl-wayland to version 1.1.14, on Nvidia driver 555.58.02,
> exiting sleep mode occurs without failure and a black screen.
> Tested with screen lock enabled and with screen lock disabled.
> Everything works flawlessly.
> Recorded the transition into sleep mode and exit from it
> with the completion of recording.

On my Nvidia 555 driver the files are located in


/etc/X11/xorg.conf.d/15-nvidia.conf
/etc/vulkan/icd.d/nvidia_icd.json

Exiting sleep mode occurs without problems and image
artifacts on the screen.

I tried moving them inside the nvidia package to a different location in

/usr/share/X11/xorg.conf.d/15-nvidia.conf
/usr/share/vulkan/icd.d/nvidia_icd.json

As is done in many other distributions.
After such a movement, when exiting sleep mode,
I received a black screen with a cursor.

Then returned file
/usr/share/X11/xorg.conf.d/15-nvidia.conf
back to
/etc/X11/xorg.conf.d/15-nvidia.conf

After that, waking up from sleep mode began to work,
but there were strong image artifacts.

After that I returned file
/usr/share/vulkan/icd.d/nvidia_icd.json
to
/etc/vulkan/icd.d/nvidia_icd.json

Wakeup from sleep mode started working correctly.
The system wakes up and works without failures.
There are no image artifacts.

In general, the placement of files in the nvidia driver package matters a lot.

(In reply to Victor Ryzhykh from comment #48)
> In general, the placement of files in the nvidia driver package matters a lot.

Continued research into waking up from sleep mode in a Wayland session.
It turned out that on kernel 6.8.12, kDE6 comes out of sleep mode, but it is impossible to use. Very strong image artifacts. Almost nothing is visible, and what is visible is constantly blinking. On kernel 6.9.10, kDE6 wakes up from sleep mode and works without failures. On kernel 6.10.1, kDE6 also works without problems after exiting sleep mode

(In reply to Victor Ryzhykh from comment #48)
> In general, the placement of files in the nvidia driver package matters a lot.

Continued research into waking up from sleep mode in a Wayland session.
It turned out that on kernel 6.8.12, KDE6 comes out of sleep mode, but it is impossible to use. Very strong image artifacts. Almost nothing is visible, and what is visible is constantly blinking. On kernel 6.9.10, KDE6 wakes up from sleep mode and works without failures. On kernel 6.10.1, KDE6 also works without problems after exiting sleep mode

Created attachment 172029 [details]
Info Center

I now understand in what cases the exit from sleep mode works normally for me.
I installed the nvidia driver modules from dkms.
The algorithm is as follows: kernel modules are compiled, all nvidia packages are installed, and then the “dracut -f” command is executed for all kernels installed on the computer.
But on kernels 6.10 and 6.11, kernel modules are not compiled at the time of installation.
All nvidia packages are installed, and the “dracut” command is executed for all kernels installed on the computer, and kernel mods are compiled the next time you boot with the selected kernel.
And with this setup, exiting sleep mode began to work correctly for me in the Wayland session.
But if, on such an Nvidia driver installation with a correctly working exit from sleep mode, you execute the “dracut -f” command, then exit from sleep mode stops working on the core where the command was executed. There will be creepy artifacts on the screen.
I have three 6.9.x kernels installed. and two 6.10.x kernels.
Now I completely uninstalled the nvidia drivers and then installed them again.
First I booted into the 6.9.9 kernel. The picture shows information from the Info Center for this kernel.
Wake up from sleep mode works. Next, to check, I run the “dracut -f” command and after rebooting, exiting standby mode stopped working.
Now I switched to the main kernel 6.10.1. After compiling the kernel modules, resuming from standby mode works.
Now you need to refrain from running the “dracut” command.

P.S.
I'm not sure if my information is useful. But for myself, at least, I clarified the situation a little.
Previously, I couldn’t understand why the sleep mode works and then stops working.
Now I put the computer into sleep mode and came out of sleep three times in a row, after which I tested the equipment.


The probe of your computer has been uploaded to the ROSA hardware DB. Thank you!

Probe URL: https://linux-hardware.org/?probe=8769fc73a2

I can confirm the latest kernel fixed the bug for amdgpu.

(In reply to Fushan Wen from comment #52)
> I can confirm the latest kernel fixed the bug for amdgpu.
I have still this issue on
   Operating System: Manjaro Linux
   KDE Plasma Version: 6.0.5
   KDE Frameworks Version: 6.4.0
   Qt Version: 6.7.2
   Kernel Version: 6.6.41-1-MANJARO (64-bit)
   Graphics Platform: X11
   Processors: 16 × AMD Ryzen 7 PRO 4750U with Radeon Graphics
   Graphics Processor: AMD Radeon Graphics
@Fushan Wen: What did you mean with "latest kernel"? I'd appreciate if someone would add [AMD] again to the summary.

(In reply to Michael from comment #53)
> (In reply to Fushan Wen from comment #52)
> > I can confirm the latest kernel fixed the bug for amdgpu.
> I have still this issue on
>    Operating System: Manjaro Linux
>    KDE Plasma Version: 6.0.5
>    KDE Frameworks Version: 6.4.0
>    Qt Version: 6.7.2
>    Kernel Version: 6.6.41-1-MANJARO (64-bit)
>    Graphics Platform: X11
>    Processors: 16 × AMD Ryzen 7 PRO 4750U with Radeon Graphics
>    Graphics Processor: AMD Radeon Graphics
> @Fushan Wen: What did you mean with "latest kernel"? I'd appreciate if
> someone would add [AMD] again to the summary.

He's either referring to kernel 6.9.12 or 6.10.2 or higher or 6.6.43 or higher, depending on whether he's running a current or LTS kernel. You're on the LTS kernel. You could try using a more recent kernel or updating to the latest LTS kernel to see if it resolves the issue for you.

(In reply to Victor Ryzhykh from comment #51)
> Previously, I couldn’t understand why the sleep mode works and then stops
> working.

I figured out what the problem was.
Nvidia developers helped.
Now waking up from sleep mode on Nvidia drivers in a wayland session always works correctly for me.
There are no glitches or image artifacts.
Here about my settings for the nvidia560 driver.

https://forums.developer.nvidia.com/t/560-release-feedback-discussion/300830/265?u=victorr2007

I added the path to the /etc/modprobe.d/nvidia-power-management.conf file to the /etc/dracut.conf.d/10-nvidia.conf file

The new file /etc/dracut.conf.d/10-nvidia560.conf now looks like this

add_drivers+=" nvidia nvidia-drm nvidia-modeset nvidia-uvm "
install_optional_items+=" /etc/modprobe.d/nvidia-power-management.conf "
install_optional_items+=" /etc/modprobe.d/nvidia560-blacklist-nouveau.conf "
install_optional_items+=" /etc/modprobe.d/nvidia560-wayland.conf "

Contents of the /etc/modprobe.d/nvidia-power-management.conf file
"options nvidia NVreg_PreserveVideoMemoryAllocations=1 NVreg_TemporaryFilePath=/var/tmp"

Contents of the /etc/modprobe.d/nvidia560-blacklist-nouveau.conf file
"blacklist nouveau"

Contents of the /etc/modprobe.d/nvidia560-wayland.conf file
"options nvidia_drm modeset=1 fbdev=1"

Now exiting sleep mode occurs without errors.

Great, sounds like it was a series of NVIDIA driver and configuration issues. Ethan, are you able to resolve these issues as well by following those steps?

To me, it sounds like the “fix” above basically boils down to NVreg_PreserveVideoMemoryAllocations=1, which is a well-known workaround:
https://wiki.archlinux.org/title/NVIDIA/Tips_and_tricks#Preserve_video_memory_after_suspend

It basically saves the entire video memory to RAM or disk, then restores it. I could be wrong, but I don't think requiring users to enable a hack is a proper fix.

Additionally, said hack doesn't work for everyone, and even Nvidia themselves marked this as experimental without a change of status for quite some time.

Personally, after trying that fix in my void Linux install(had to recreate the systemd scripts on runit), suspend would no longer work at all and my fans would start spinning at full capacity.

Searching online I found other users experiencing the exact same issue after employing this hack. Wayland worked fine on KDE 5 with the exact same setup btw.

(In reply to Ilya Bizyaev from comment #57)
> To me, it sounds like the “fix” above basically boils down to
> NVreg_PreserveVideoMemoryAllocations=1, which is a well-known workaround:
> https://wiki.archlinux.org/title/NVIDIA/
> Tips_and_tricks#Preserve_video_memory_after_suspend
> 
> It basically saves the entire video memory to RAM or disk, then restores it.
> I could be wrong, but I don't think requiring users to enable a hack is a
> proper fix.

The fact is that Nvidia is on Wayland
does not directly use files from /etc/modprobe.d/
Also Nvidia on Wayland does not use file /etc/X11/xorg.conf.d/nvidia.conf
Will boot and work on Wayland, even if there is no file on the system /etc/X11/xorg.conf.d/nvidia.conf
It just won't be possible to start session x11.
All these files are used only in session x11.
Because of this, parameter NVreg_PreserveVideoMemoryAllocations=1, is not taken into account when entering sleep mode.
For a Wiland session, configs for Nvidia must either be written into the kernel parameters via file /etc/default/grub,
or written to the kernel initrd using draсut in file /etc/dracut.conf.d/10-nvidia.conf.
I make myself an nvidia package without using file /etc/default/grub for configuration, and only file /etc/dracut.conf.d/10-nvidia.conf is used for configuration.
Everything works fine for me, both X11 and Wayland.
I make this nvidia package https://abf.rosalinux.ru/x11_backports/nvidia560

(In reply to Ilya Bizyaev from comment #57)
> To me, it sounds like the “fix” above basically boils down to
> NVreg_PreserveVideoMemoryAllocations=1, which is a well-known workaround:
> https://wiki.archlinux.org/title/NVIDIA/
> Tips_and_tricks#Preserve_video_memory_after_suspend
> 
> It basically saves the entire video memory to RAM or disk, then restores it.
> I could be wrong, but I don't think requiring users to enable a hack is a
> proper fix.

I will return to this issue again.
Before the latest changes to my configs, I periodically encountered problems after exiting sleep mode.
This only happened when the dracut command was run after installing the nvidia kernel modules.
If the dracut command was not executed after installing kernel modules, then I had no problems after waking up from sleep mode.
Recently, after getting another error when waking up from sleep, I sent the log file to the nvidia developers, in this message

https://forums.developer.nvidia.com/t/560-release-feedback-discussion/300830/241?u=victorr2007

I got a reply a few days later in this message
https://forums.developer.nvidia.com/t/560-release-feedback-discussion/300830/262?u=victorr2007
It turned out that file /etc/modprobe.d/nvidia-power-management.conf was ignored in the wayland session.

Then I decided to add a record about this file to file /etc/dracut.conf.d/10-nvidia560.conf,
where I had previously added other configuration files for use.
It turned out to be the right decision.
Now everything works perfectly for me.
I'm not sure that kde can restore video memory on its own when exiting sleep mode.

Thanks everyone. So I brought this to the attention of a KWin developer who brought it to the attention of an NVIDIA developer.

The conclusion here is that NVreg_PreserveVideoMemoryAllocations=1 is not a workaround, and *should be* used. The only reason it's not turned on by default is because if it's turned on without the appropriate pre-suspend hooks in place, suspend will get broken. NVIDIA distributed systemd unit files for these hooks, but they don't trust distros and users to install and activate them, and of course those using non-systemd distros will have to figure something else out as well. So they leave it off by default to avoid having to handle those cases.

This information has been added to https://community.kde.org/Distributions/Packaging_Recommendations#Proprietary_NVidia_driver_configuration, and I've emailed distros about it.

So from a KDE perspective this is basically a downstream/distro issue at this point. I encourage everyone to go contact their distros about it as well, and ideally submit patches if you're a distro packager or like to play one on TV.

(In reply to Nate Graham from comment #61)
> Thanks everyone. So I brought this to the attention of a KWin developer who
> brought it to the attention of an NVIDIA developer.
> 
> The conclusion here is that NVreg_PreserveVideoMemoryAllocations=1 is not a
> workaround, and *should be* used. The only reason it's not turned on by
> default is because if it's turned on without the appropriate pre-suspend
> hooks in place, suspend will get broken. NVIDIA distributed systemd unit
> files for these hooks, but they don't trust distros and users to install and
> activate them, and of course those using non-systemd distros will have to
> figure something else out as well. So they leave it off by default to avoid
> having to handle those cases.
> 
> This information has been added to
> https://community.kde.org/Distributions/
> Packaging_Recommendations#Proprietary_NVidia_driver_configuration, and I've
> emailed distros about it.
> 
> So from a KDE perspective this is basically a downstream/distro issue at
> this point. I encourage everyone to go contact their distros about it as
> well, and ideally submit patches if you're a distro packager or like to play
> one on TV.

Honestly, replicating the exact same systemd scripts you mention to get suspend working on runit did not work for me.

Looking online I found other users experiencing the same exact problem when enabling NVreg_PreserveVideoMemoryAllocations=1 even on systemd distros using the exact same setup.

Back to debugging I guess.

It's quite possible there are still bugs, or the hooks are interfering with some other distro-provided or user-initiated setting.

Hassles like this are why I personally avoid NVIDIA hardware, FWIW.

Created attachment 173326 [details]
My file for correct work of exit from sleep mode

(In reply to Fotios Valasiadis from comment #62
> Back to debugging I guess.
For me, it turned out to be a revelation that for Wayland, to exit sleep mode, each necessary kernel module needs to be entered into the file /etc/dracut.conf.d/10-nvidia.conf
So far, only VirtualBox modules have not been added there.
I had to add network modules so that after waking up from sleep mode, the network would start working.
After a long period of sleep, the network could not connect.
On kernel 6.10.X, these network modules are already in the kernel,
so I removed the last two lines from the file /etc/dracut.conf.d/10-nvidia.conf

(In reply to Victor Ryzhykh from comment #64)
> Created attachment 173326 [details]
> My file for correct work of exit from sleep mode
> 
> (In reply to Fotios Valasiadis from comment #62
> > Back to debugging I guess.
> For me, it turned out to be a revelation that for Wayland, to exit sleep
> mode, each necessary kernel module needs to be entered into the file
> /etc/dracut.conf.d/10-nvidia.conf
> So far, only VirtualBox modules have not been added there.
> I had to add network modules so that after waking up from sleep mode, the
> network would start working.
> After a long period of sleep, the network could not connect.
> On kernel 6.10.X, these network modules are already in the kernel,
> so I removed the last two lines from the file
> /etc/dracut.conf.d/10-nvidia.conf

Fedora works OOTB on wayland on that PC with a 1050 Ti so yeah the issue is definitely solvable.

I (gladly) don't use said PC anymore though, and linux on it was a pain for more than that. Nvidia not supporting VRAM spilling onto system RAM made it unusable even for 1080p couch gaming at 60 fps. Dual boot windows it is to play games that work perfectly fine with proton, sadge.

But I am thinking I will still look into solving this issue in void linux because I don't value my time.

(In reply to Nate Graham from comment #63)
> It's quite possible there are still bugs, or the hooks are interfering with
> some other distro-provided or user-initiated setting.
> 
> Hassles like this are why I personally avoid NVIDIA hardware, FWIW.

I had my first laptop with ati radeon.
I was disappointed in it when the manufacturer's support quickly ended.
In 2010, I gave it to my son.
Since then, I have had six more laptops.
All with an nvidia video card.
And now I have my third desktop computer,
and all were with an nvidia video card.
This is the best video card.
And it has no problems with kde.
There has never been and never will be a stronger fan of kde than me.
And I am just an amateur, not a crazy fan, of nvida.
They work great together for me.
There are nuances, but I hope they can be solved.