SUMMARY Screens don't light up after resuming until I hit my keyboard. I was able to reproduce this issue using either only my laptop's internal screen while running on battery, or only external monitors while running on power adapter (clamshell mode). I enabled Powerdevil Full Debug log and captured logs in both scenarios. STEPS TO REPRODUCE (Internal screen) 1. Close lid to sleep 2. Open lid. It wakes up but the screen's black 3. Hit any key on the keyboard, the internal screen will light up The laptop was running on battery and /sys/bus/pci/devices/0000:01:00.0/power/runtime_status said 'suspended'. STEPS TO REPRODUCE (External monitors, clamshell mode) 1. Sleep (Krunner -> Sleep) 2. Wake up the laptop using either keyboard or Wake-on-LAN 3. All displays, including the laptop's internal one, stay black 4. Hit any key on the keyboard, external displays will light up Two displays connected via HDMI and USB-C (DP Alt) each. /sys/bus/pci/devices/0000:01:00.0/power/runtime_status said 'active' (HDMI and DP are wired to the NVIDIA card). I opened my laptop's lid to reach the internal keyboard in Step 3, so that the 'Lid opened / closed' logs could serve as dividers. OBSERVED RESULT Screens don't light up until there are some user interactions. EXPECTED RESULT Screens light up automatically. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.5.5 KDE Frameworks Version: 6.22.0 Qt Version: 6.10.1 Kernel Version: 6.18.7-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 20 × 12th Gen Intel® Core™ i9-12900H Memory: 64 GiB of RAM (62.5 GiB usable) Graphics Processor 1: Intel® Iris® Xe Graphics Graphics Processor 2: NVIDIA GeForce RTX 3080 Ti Laptop GPU Manufacturer: LENOVO Product Name: 21DECTO1WW System Version: ThinkPad X1 Extreme Gen 5 Drivers: iGPU: i915 NVIDIA: nvidia-open-dkms 590.48.01-2 $ sudo systool -vm i915 Module = "i915" Parameters: disable_display = "N" disable_power_well = "-1" dmc_firmware_path = "(null)" edp_vswing = "0" enable_dc = "-1" enable_dmc_wl = "-1" enable_dp_mst = "Y" enable_dpcd_backlight= "-1" enable_dpt = "Y" enable_dsb = "Y" enable_fbc = "1" enable_flipq = "N" enable_guc = "3" enable_gvt = "N" enable_hangcheck = "Y" enable_ips = "Y" enable_panel_replay = "-1" enable_psr2_sel_fetch= "Y" enable_psr = "-1" enable_sagv = "Y" error_capture = "Y" force_probe = "*" force_reset_modeset_test= "N" gsc_firmware_path = "(null)" guc_firmware_path = "(null)" guc_log_level = "-1" huc_firmware_path = "(null)" invert_brightness = "0" lmem_bar_size = "0" lmem_size = "0" load_detect_test = "N" lvds_channel_mode = "0" memtest = "N" mitigations = "auto" mmio_debug = "0" modeset = "-1" nuclear_pageflip = "N" panel_use_ssc = "-1" psr_safest_params = "N" request_timeout_ms = "20000" reset = "3" vbt_firmware = "(null)" vbt_sdvo_panel_type = "-1" verbose_state_checks= "Y" $ cat /proc/driver/nvidia/params ResmanDebugLevel: 4294967295 RmLogonRC: 1 ModifyDeviceFiles: 1 DeviceFileUID: 0 DeviceFileGID: 0 DeviceFileMode: 438 InitializeSystemMemoryAllocations: 1 UsePageAttributeTable: 1 EnableMSI: 1 EnablePCIeGen3: 0 MemoryPoolSize: 0 KMallocHeapMaxSize: 0 VMallocHeapMaxSize: 0 IgnoreMMIOCheck: 0 EnableStreamMemOPs: 0 EnableUserNUMAManagement: 1 NvLinkDisable: 0 RmProfilingAdminOnly: 1 PreserveVideoMemoryAllocations: 0 EnableS0ixPowerManagement: 0 S0ixPowerManagementVideoMemoryThreshold: 256 DynamicPowerManagement: 3 DynamicPowerManagementVideoMemoryThreshold: 200 TegraGpuPgMask: 0 RegisterPCIDriver: 1 EnablePCIERelaxedOrderingMode: 0 EnableResizableBar: 0 EnableGpuFirmware: 18 EnableGpuFirmwareLogs: 2 RmNvlinkBandwidthLinkCount: 0 EnableDbgBreakpoint: 0 OpenRmEnableUnsupportedGpus: 1 DmaRemapPeerMmio: 1 ImexChannelCount: 2048 CreateImexChannel0: 0 GrdmaPciTopoCheckOverride: 0 EnableSystemMemoryPools: 529 CoherentGPUMemoryMode: "" RegistryDwords: "" RegistryDwordsPerDevice: "" RmMsg: "" GpuBlacklist: "" TemporaryFilePath: "/var/tmp" ExcludedGpus: "" ADDITIONAL INFORMATION Originally reported at Bug 513150. I didn't have this issue using X11.
Created attachment 189241 [details] Logs when using the internal screen
Created attachment 189242 [details] Logs when using the external displays
> I opened my laptop's lid to reach the internal keyboard in Step 3, so that the 'Lid opened / closed' logs could serve as dividers. *in Step 4*
Okay, so there seem to be two things happening here. I see > Feb 06 00:23:20 FredArch kwin_wayland[2633]: Atomic modeset test failed! Permission denied > Feb 06 00:23:20 FredArch kwin_wayland[2633]: Setting dpms mode failed! which certainly explains why the screens don't turn on, but also > Detected GPU reset on secondary GPU /dev/dri/card0 which is also potentially a problem. Let's ignore the GPU reset for now and find out why KWin doesn't have permissions to turn the screen back on. Please follow https://invent.kde.org/plasma/kwin/-/wikis/Debugging/Debugging-DRM-issues and get a drm debug log from a sleep+wake cycle. It will hopefully have more information about what's going on.
Created attachment 189286 [details] DRM debug log. Captured when using external displays The context around the 'Permission denied' logs in journalctl was > Feb 07 01:24:09 FredArch rtkit-daemon[3544]: Resumed scheduling 6 threads. > Feb 07 01:24:09 FredArch kernel: i915 0000:00:02.0: [drm:drm_file_free] comm="lact", pid=2669, dev=0xe280, open_count=23 > Feb 07 01:24:09 FredArch lact[2669]: 2026-02-06T14:24:09.871308Z INFO lact_daemon::suspend: suspend/resume event detected, reloading config > Feb 07 01:24:09 FredArch kwin_wayland[3470]: Atomic modeset test failed! Permission denied > Feb 07 01:24:09 FredArch kwin_wayland[3470]: Setting dpms mode failed! > Feb 07 01:24:09 FredArch kwin_wayland[3470]: Atomic modeset test failed! Permission denied > Feb 07 01:24:09 FredArch kwin_wayland[3470]: Setting dpms mode failed! > Feb 07 01:24:09 FredArch kernel: nvidia 0000:01:00.0: [drm:drm_ioctl] comm="kwin_wayland" pid=3470, dev=0xe200, auth=1, DRM_IOCTL_MODE_CREATEPROPBLOB > Feb 07 01:24:09 FredArch kernel: nvidia 0000:01:00.0: [drm:drm_ioctl] comm="kwin_wayland" pid=3470, dev=0xe200, auth=1, DRM_IOCTL_MODE_ATOMIC > Feb 07 01:24:09 FredArch kernel: nvidia 0000:01:00.0: [drm:drm_ioctl] comm="kwin_wayland", pid=3470, ret=-13 > Feb 07 01:24:09 FredArch kernel: nvidia 0000:01:00.0: [drm:drm_ioctl] comm="kwin_wayland" pid=3470, dev=0xe200, auth=1, DRM_IOCTL_MODE_DESTROYPROPBLOB > Feb 07 01:24:09 FredArch kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 165 (2) > Feb 07 01:24:09 FredArch kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 165 (1) > Feb 07 01:24:09 FredArch kernel: nvidia 0000:01:00.0: [drm:drm_ioctl] comm="kwin_wayland" pid=3470, dev=0xe200, auth=1, DRM_IOCTL_MODE_CREATEPROPBLOB > Feb 07 01:24:09 FredArch kernel: nvidia 0000:01:00.0: [drm:drm_ioctl] comm="kwin_wayland" pid=3470, dev=0xe200, auth=1, DRM_IOCTL_MODE_ATOMIC > Feb 07 01:24:09 FredArch kernel: nvidia 0000:01:00.0: [drm:drm_ioctl] comm="kwin_wayland", pid=3470, ret=-13 > Feb 07 01:24:09 FredArch kernel: nvidia 0000:01:00.0: [drm:drm_ioctl] comm="kwin_wayland" pid=3470, dev=0xe200, auth=1, DRM_IOCTL_MODE_DESTROYPROPBLOB > Feb 07 01:24:09 FredArch kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 165 (2) > Feb 07 01:24:09 FredArch kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 165 (1)
Okay, so one suspicious thing is this: > [ 115.096076] i915 0000:00:02.0: [drm:drm_ioctl] comm="systemd-logind" pid=2439, dev=0xe201, auth=1, DRM_IOCTL_DROP_MASTER > [ 115.096115] nvidia 0000:01:00.0: [drm:drm_ioctl] comm="systemd-logind" pid=2439, dev=0xe200, auth=1, DRM_IOCTL_DROP_MASTER right before KWin would normally turn off the screens before suspend. After wakeup, it does > [ 145.491052] i915 0000:00:02.0: [drm:drm_ioctl] comm="systemd-logind" pid=2439, dev=0xe201, auth=1, DRM_IOCTL_SET_MASTER > [ 145.491068] nvidia 0000:01:00.0: [drm:drm_ioctl] comm="systemd-logind" pid=2439, dev=0xe200, auth=1, DRM_IOCTL_SET_MASTER but only after KWin attempts to turn the display on again. I don't quite understand why systemd would do that, and it certainly doesn't do that on my PC. My first suspicion would be that lact is doing something weird, another possibility is that you have a service or something that causes this. The screens turning on when you press something on the keyboard is most likely because that just triggers a repaint, and makes KWin try again to turn the display(s) on. Can you try removing lact and check if it still happens then?
Created attachment 189316 [details] DRM debug log after disabling lact. Captured when using external displays > Can you try removing lact and check if it still happens then? Sure thing. I disabled lact and rebooted my laptop just in case. But unfortunately I still had the issue. By the way I noticed that there were 'Atomic modeset test failed! Permission denied' logs when it was entering sleep state too (so were there last time when I had lact on). journalctl context when entering sleep state: > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Device /dev/i2c-14 lacks R/W permissions > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Device /dev/i2c-15 lacks R/W permissions > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Device /dev/i2c-16 lacks R/W permissions > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Device /dev/i2c-17 lacks R/W permissions > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Removing connected display on bus 9 > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] (dw_remove_display_by_businfo) No Display_Ref found for i2c bus: 9 > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Removing connected display on bus 16 > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Emitting DDCA_Display_Status_Event[ 61.292: DDCA_EVENT_DISPLAY_DISCONNECTED, card0-HDMI-A-2, dref: DDCA_Display_Ref[2], io_path:/dev/i2c-16, ddc working: false] > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Starting 1 callback threads > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] libddcutil callback thread 0x7fee10016f40 started > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Started 1 event callback thread(s) > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Removing connected display on bus 17 > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Emitting DDCA_Display_Status_Event[ 61.292: DDCA_EVENT_DISPLAY_DISCONNECTED, card0-DP-6, dref: DDCA_Display_Ref[3], io_path:/dev/i2c-17, ddc working: false] > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Starting 1 callback threads > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 6063] Invoking callback function 0x7fee497c57f0 for event DDCA_Display_Status_Event[ 61.292: DDCA_EVENT_DISPLAY_DISCONNECTED, card0-HDMI-A-2, dref: DDCA_Display_Ref[2], io_path:/dev/i2c > -16, ddc working: false] in this thread [ 6063] > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 6063] Callback function 0x7fee497c57f0 for event DDCA_Display_Status_Event[ 61.292: DDCA_EVENT_DISPLAY_DISCONNECTED, card0-HDMI-A-2, dref: DDCA_Display_Ref[2], io_path:/dev/i2c-16, ddc > working: false] complete > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 6064] Invoking callback function 0x7fee497c57f0 for event DDCA_Display_Status_Event[ 61.292: DDCA_EVENT_DISPLAY_DISCONNECTED, card0-DP-6, dref: DDCA_Display_Ref[3], io_path:/dev/i2c-17, > ddc working: false] in this thread [ 6064] > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 6064] Callback function 0x7fee497c57f0 for event DDCA_Display_Status_Event[ 61.292: DDCA_EVENT_DISPLAY_DISCONNECTED, card0-DP-6, dref: DDCA_Display_Ref[3], io_path:/dev/i2c-17, ddc work > ing: false] complete > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] libddcutil callback thread 0x7fee1001f590 started > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Started 1 event callback thread(s) > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Udev event detected > Feb 07 14:22:39 FredArch kwin_wayland[3454]: Atomic modeset test failed! Permission denied > Feb 07 14:22:39 FredArch kernel: i915 0000:00:02.0: [drm:drm_ioctl] comm="kwin_wayland" pid=3454, dev=0xe201, auth=1, DRM_IOCTL_MODE_ATOMIC > Feb 07 14:22:39 FredArch kwin_wayland[3454]: Applying output configuration failed! > Feb 07 14:22:39 FredArch kernel: i915 0000:00:02.0: [drm:drm_ioctl] comm="kwin_wayland", pid=3454, ret=-13 > Feb 07 14:22:39 FredArch kwin_wayland[3454]: Atomic modeset test failed! Permission denied > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Device /dev/i2c-0 lacks R/W permissions > Feb 07 14:22:39 FredArch kernel: i915 0000:00:02.0: [drm:drm_ioctl] comm="kwin_wayland" pid=3454, dev=0xe201, auth=1, DRM_IOCTL_MODE_ATOMIC > Feb 07 14:22:39 FredArch kwin_wayland[3454]: Applying output configuration failed! > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Device /dev/i2c-1 lacks R/W permissions > Feb 07 14:22:39 FredArch kernel: i915 0000:00:02.0: [drm:drm_ioctl] comm="kwin_wayland", pid=3454, ret=-13 > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Device /dev/i2c-2 lacks R/W permissions > Feb 07 14:22:39 FredArch kernel: i915 0000:00:02.0: [drm:drm_ioctl] comm="QSGRenderThread" pid=5940, dev=0xe280, auth=0, I915_GEM_SET_TILING > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Device /dev/i2c-3 lacks R/W permissions > Feb 07 14:22:39 FredArch kernel: i915 0000:00:02.0: [drm:drm_ioctl] comm="QSGRenderThread" pid=5940, dev=0xe280, auth=0, DRM_IOCTL_PRIME_HANDLE_TO_FD > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Device /dev/i2c-4 lacks R/W permissions > Feb 07 14:22:39 FredArch kernel: i915 0000:00:02.0: [drm:drm_ioctl] comm="QSGRenderThread" pid=5940, dev=0xe280, auth=0, DRM_IOCTL_PRIME_HANDLE_TO_FD > Feb 07 14:22:39 FredArch org_kde_powerdevil[3781]: [ 4027] Device /dev/i2c-5 lacks R/W permissions > Feb 07 14:22:39 FredArch kernel: i915 0000:00:02.0: [drm:drm_ioctl] comm="QSGRenderThread" pid=5940, dev=0xe280, auth=0, DRM_IOCTL_PRIME_HANDLE_TO_FD journalctl context when resuming: > Feb 07 14:22:54 FredArch rtkit-daemon[3565]: Resuming known real-time threads. > Feb 07 14:22:54 FredArch rtkit-daemon[3565]: Successfully made thread 3734 of process 3729 owned by '1000' RT at priority 20. > Feb 07 14:22:54 FredArch rtkit-daemon[3565]: Successfully made thread 3729 of process 3729 owned by '1000' high priority at nice level -11. > Feb 07 14:22:54 FredArch rtkit-daemon[3565]: Successfully made thread 3564 of process 3559 owned by '1000' RT at priority 20. > Feb 07 14:22:54 FredArch rtkit-daemon[3565]: Successfully made thread 3559 of process 3559 owned by '1000' high priority at nice level -11. > Feb 07 14:22:54 FredArch rtkit-daemon[3565]: Successfully made thread 3573 of process 3560 owned by '1000' RT at priority 20. > Feb 07 14:22:54 FredArch rtkit-daemon[3565]: Successfully made thread 3560 of process 3560 owned by '1000' high priority at nice level -11. > Feb 07 14:22:54 FredArch rtkit-daemon[3565]: Resumed scheduling 6 threads. > Feb 07 14:22:54 FredArch suspend[6497]: nvidia-resume.service > Feb 07 14:22:54 FredArch logger[6497]: <13>Feb 7 14:22:54 suspend: nvidia-resume.service > Feb 07 14:22:54 FredArch kernel: i915 0000:00:02.0: [drm:intel_power_well_enable [i915]] enabling always-on > Feb 07 14:22:54 FredArch systemd[1]: nvidia-resume.service: Deactivated successfully. > Feb 07 14:22:54 FredArch kwin_wayland[3454]: Atomic modeset test failed! Permission denied > Feb 07 14:22:54 FredArch kwin_wayland[3454]: Setting dpms mode failed! > Feb 07 14:22:54 FredArch kwin_wayland[3454]: Atomic modeset test failed! Permission denied > Feb 07 14:22:54 FredArch kwin_wayland[3454]: Setting dpms mode failed! > Feb 07 14:22:54 FredArch systemd[1]: Finished NVIDIA system resume actions. > Feb 07 14:22:54 FredArch kernel: nvidia 0000:01:00.0: [drm:drm_ioctl] comm="kwin_wayland" pid=3454, dev=0xe200, auth=1, DRM_IOCTL_MODE_CREATEPROPBLOB > Feb 07 14:22:54 FredArch kernel: nvidia 0000:01:00.0: [drm:drm_ioctl] comm="kwin_wayland" pid=3454, dev=0xe200, auth=1, DRM_IOCTL_MODE_ATOMIC > Feb 07 14:22:54 FredArch kernel: nvidia 0000:01:00.0: [drm:drm_ioctl] comm="kwin_wayland", pid=3454, ret=-13 > Feb 07 14:22:54 FredArch kernel: nvidia 0000:01:00.0: [drm:drm_ioctl] comm="kwin_wayland" pid=3454, dev=0xe200, auth=1, DRM_IOCTL_MODE_DESTROYPROPBLOB > Feb 07 14:22:54 FredArch kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 165 (2) > Feb 07 14:22:54 FredArch kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 165 (1) > Feb 07 14:22:54 FredArch kernel: nvidia 0000:01:00.0: [drm:drm_ioctl] comm="kwin_wayland" pid=3454, dev=0xe200, auth=1, DRM_IOCTL_MODE_CREATEPROPBLOB > Feb 07 14:22:54 FredArch kernel: nvidia 0000:01:00.0: [drm:drm_ioctl] comm="kwin_wayland" pid=3454, dev=0xe200, auth=1, DRM_IOCTL_MODE_ATOMIC > Feb 07 14:22:54 FredArch kernel: nvidia 0000:01:00.0: [drm:drm_ioctl] comm="kwin_wayland", pid=3454, ret=-13 > Feb 07 14:22:54 FredArch kernel: nvidia 0000:01:00.0: [drm:drm_ioctl] comm="kwin_wayland" pid=3454, dev=0xe200, auth=1, DRM_IOCTL_MODE_DESTROYPROPBLOB > Feb 07 14:22:54 FredArch kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 165 (2) > Feb 07 14:22:54 FredArch kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 165 (1)
Okay. So then we can be certain that > [ 110.245823] nvidia 0000:01:00.0: [drm:drm_ioctl] comm="systemd-logind" pid=2467, dev=0xe200, auth=1, DRM_IOCTL_DROP_MASTER + > [ 110.245919] i915 0000:00:02.0: [drm:drm_ioctl] comm="systemd-logind" pid=2467, dev=0xe201, auth=1, DRM_IOCTL_DROP_MASTER is from something else. I looked through logind code, and it only calls this when the session is paused, iow when a VT switch happens. I did some more digging, and the nvidia driver's sleep handling script (/usr/bin/nvidia-sleep.sh) does a VT switch before suspend, and switches back after wakeup only after doing some tasks in the driver. I'm quite unhappy about that situation, but assuming that delaying suspend also delays that script, we should be able to deal with it.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/8776