Blank screen when awake from sleep

felipescotti · 2025-11-10 23:21:00

Hello everyone!

My system is leaving me with a blank screen when awake from sleep let`s say 90% of the time.
The other 10% it works, but if I try to suspend again, the next time awake will let my screen blank again.
Keyboard commands like (ctrl + alt + del) or (crtl + F2) F3 do not respond most of the times, leaving me with the last option short press power button (OS shutdown normally and video also work showing the shutdown process) and a few times when messing around trying to find a solution I had to hold press power button.

I failed to find out how to remap SysRq (in order to use REISUB) and my usb keyboard does not have printscreen (The solutions that I found apparently only work with ps/2 keyboards).

I run a Uki, FDE, EFI Stub, i7 9700k, RTX 2080 super, no dysplay manager, only startx and DWM, no swap then only suspend to RAM (not hibernation it's off on logind.conf).
It's multimoninor and the screens connected to integrated graphics also get blank

Things that I tried:

Run LTS kernel using DKMS
Change Bios options: various combinations on Native PCIE enable, Native ASPM, PEG0, (Normally I leave all off). Change from PEG to IGD
Install acpi_call-dkms and acpi (already uninstalled' em)
My kernel parameters (/etc/cmdline/root.conf) has now:
"nvidia_drm.modeset=1 NVreg_PreserveVideoMemoryAllocations=1 hpet=disable"
cat /sys/module/pcie_aspm/parameters/policy is [default] performance powersave powersupersave
.xinit has:
xset s off
xset -dpms

Run Screen at 60hz instead of 120hz
Force full composition in nvidia-settings is on and saved on /etc/X11/xorg.conf

Nov 10 19:15:21 systemd[1]: systemd-suspend.service: Deactivated successfully.
Nov 10 19:15:21 systemd[1]: Finished System Suspend.
Nov 10 19:15:21 systemd[1]: Stopped target Sleep.
Nov 10 19:15:21 systemd[1]: Reached target Suspend.
Nov 10 19:15:21 systemd[1]: Starting NVIDIA system resume actions...
Nov 10 19:15:21 systemd[1]: Stopped target Suspend.
Nov 10 19:15:21 suspend[1127]: nvidia-resume.service
Nov 10 19:15:21 logger[1127]: <13>Nov 10 19:15:21 suspend: nvidia-resume.service
Nov 10 19:15:21 systemd-logind[583]: Operation 'suspend' finished.
Nov 10 19:15:21 systemd-resolved[488]: Closing all remaining TCP connections.
Nov 10 19:15:21 systemd-resolved[488]: Resetting learnt feature levels on all servers.
Nov 10 19:15:21 systemd-networkd[486]: wlan0: Reconfiguring with /etc/systemd/network/25-wireless.network.
Nov 10 19:15:21 systemd[1]: nvidia-resume.service: Deactivated successfully.
Nov 10 19:15:21 systemd[1]: Finished NVIDIA system resume actions.
Nov 10 19:15:21 systemd-logind[583]: Watching system buttons on /dev/input/event4 (Logitech Gaming Mouse G502 Keyboard)
Nov 10 19:15:21 systemd-logind[583]: Watching system buttons on /dev/input/event5 (SteelSeries SteelSeries Apex 3 TKL)
Nov 10 19:15:22 systemd-logind[583]: Watching system buttons on /dev/input/event7 (SteelSeries SteelSeries Apex 3 TKL Consumer Control)
Nov 10 19:15:22 systemd-logind[583]: Watching system buttons on /dev/input/event6 (SteelSeries SteelSeries Apex 3 TKL)

Edit: Grammar!
Thanks in advance!

Last edited by felipescotti (2025-11-13 22:03:21)

seth · 2025-11-11 08:56:07

"nvidia_drm.modeset=1 NVreg_PreserveVideoMemoryAllocations=1 hpet=disable"

"nvidia.NVreg_PreserveVideoMemoryAllocations=1", but it's also the default

I failed to find out how to remap SysRq (in order to use REISUB) and my usb keyboard does not have printscreen (The solutions that I found apparently only work with ps/2 keyboards).

Can you ssh into the system?
Is the posted snippet from a good or bad suspend? It lacks entrance and signs of a (soft) reboot.

Previously ucsi_ccg and nvidia_uvm have shown up as spoil-spots, you could try to blacklist those.
(One is the usb controller on your GPU for VR goggles and the other is CUDA related)

felipescotti · 2025-11-12 16:43:15

Hello Seth! How are you? I hope you are well and thanks again for answering.

seth wrote:

"nvidia.NVreg_PreserveVideoMemoryAllocations=1", but it's also the default

Yeap, I set that for test purposes, normally it is set as your previous recomendation:
initcall_blacklist=simpledrm_platform_driver_init nvidia_drm.modeset=1
Despite that the wiki now states that DRM defaults to enabled on newer nvidia-utils
"$ sudo cat /sys/module/nvidia_drm/parameters/modeset" returns "Y"

seth wrote:

Can you ssh into the system?

ssh like remotely? I never used ssh before (Gotta have to learn that!)
Wake up from suspend works from console and the issue only occurs when suspended from DWM/X11.

seth wrote:

Is the posted snippet from a good or bad suspend? It lacks entrance and signs of a (soft) reboot.

It is the bad: $ systemctl suspend > woke up blank > short press power button (shutdown) > turn back on > journalctl -b -1 (I posted only the part which I thought it could be the issue).
Please, let me know if more is needed.

seth wrote:

Previously ucsi_ccg and nvidia_uvm have shown up as spoil-spots, you could try to https://wiki.archlinux.org/title/Kernel … ]blacklist those.
(One is the usb controller on your GPU for VR goggles and the other is CUDA related)

Blacklisting ucsi_ccg make it get rid of these errors:

kernel: nvidia-gpu 0000:01:00.3: i2c timeout error e0000000
Nov 07 16:19:03 kernel: ucsi_ccg 0-0008: i2c_transfer failed -110
Nov 07 16:19:03 kernel: ucsi_ccg 0-0008: ucsi_ccg_init failed - -110
Nov 07 16:19:03 kernel: ucsi_ccg 0-0008: probe with driver ucsi_ccg failed with error -110

As for nvidia_uvm there's:

nvidia_uvm: module uses symbols nvUvmInterfaceDisableAccessCntr from proprietary module nvidia, inheriting taint.

Should I keep it blacklisted?

Apparently is USB/Graphics related but quite intermitent:
I did a bunch of tests removing usb cables one by one (reboot and suspend for each of it).
At first removing the USB headset was giving the OS a good wake up and the issue was occuring if headset was connected to any motherboard usb port but apparently not if connected to a PciE card Usb port

Then I did some tinkering and the issue was not on headset anymore but on the mouse.
Waking up is working as far as the mouse is not connected (everything else is connected) (repeated tests and reboots done).

Did not solve (Bios configs):
Setting USB Standby Power at S3/S4/S5 [Disabled], XHCI Hand-off [Diasbled] and Legacy USB Support [Auto] Wake Up Event > Resume by USB Device [Disabled]

$ cat /sys/module/pcie_aspm/parameters/policy
[default] performance powersave powersupersave

$ systemctl is-enabled nvidia-suspend.service nvidia-hibernate.service nvidia-resume.service
enabled
enabled
enabled

When the issue was on headset:

$ journalctl -b -1 -p 3 -o cat
x86/cpu: SGX disabled or unsupported by BIOS.
usb 1-1: unable to read config index 0 descriptor/all
usb 1-1: can't read configurations, error -71
/etc/udev/rules.d/42-knobster.rules:1 Group 'F***' is not a system group, ignoring.
usb 1-1: 1:1: cannot get freq at ep 0x81
usb 1-1: 2:1: cannot get freq at ep 0x1
usb 1-1: 4:1: cannot get freq at ep 0x2

When the issue was on mouse:

$ journalctl -b -1 -p 3 -o cat
x86/cpu: SGX disabled or unsupported by BIOS.

usb 1-12: 1:1: cannot get freq at ep 0x81
usb 1-12: 2:1: cannot get freq at ep 0x1
usb 1-12: 1:1: cannot get freq at ep 0x81
usb 5-1.2: device descriptor read/all, error -32

May these warnings be related?:

mkinitcpio:
WARNING: Possibly missing firmware for module: 'xhci_pci_renesas'
WARNING: Possibly missing firmware for module: 'qat_6xxx'

Journalctl: 
xhci_hcd 0000:01:00.2: xHC error in resume, USBSTS 0x401, Reinit

Journalctl:
kernel: usb: port power management may be unreliable

I installed:
https://aur.archlinux.org/packages/upd72020x-fw (Aparently it was not a good idea) it starts to get:

$ journalctl -b -1 -p 3 -o cat
x86/cpu: SGX disabled or unsupported by BIOS.

usb 1-12: 1:1: cannot get freq at ep 0x81
usb 1-12: 4:1: cannot get freq at ep 0x2
usb 1-12: 2:1: cannot get freq at ep 0x1
xhci-pci-renesas 0000:05:00.0: PCI post-resume error -110!
xhci-pci-renesas 0000:05:00.0: HC died; cleaning up
xhci-pci-renesas 0000:05:00.0: PM: dpm_run_callback(): pci_pm_resume returns -110
xhci-pci-renesas 0000:05:00.0: PM: failed to resume async: error -110

$ journalctl -b -p 3 -o cat
x86/cpu: SGX disabled or unsupported by BIOS.
xhci-pci-renesas 0000:05:00.0: Download to external ROM TO: 20
usb 1-12: 2:1: cannot get freq at ep 0x1

usb 1-12: 1:1: cannot get freq at ep 0x81
usb 1-12: 2:1: cannot get freq at ep 0x1

Not sure if it relates but at some specific point it got:

kernel: xhci-pci-renesas 0000:05:00.0: PCI post-resume error -110!
kernel: xhci-pci-renesas 0000:05:00.0: HC died; cleaning up
kernel: xhci-pci-renesas 0000:05:00.0: PM: dpm_run_callback(): pci_pm_resume returns -110
kernel: xhci-pci-renesas 0000:05:00.0: PM: failed to resume async: error -110

And some: "stop job running for Rule-based Manager for Device Events and Files"

Last edited by felipescotti (2025-11-13 22:04:06)

seth · 2025-11-12 19:31:26

ssh like remotely? I never used ssh before (Gotta have to learn that!)

Yes. https://wiki.archlinux.org/title/OpenSSH

Wake up from suspend works from console and the issue only occurs when suspended from DWM/X11.

Please, let me know if more is needed.

Yes, please. At least entrance (you initiating the sleep) all the way to the next boot, in doubt the entire journal for that boot.

Should I keep it blacklisted?

it's not but it would be one contender.

Though w/

Waking up is working as far as the mouse is not connected (everything else is connected) (repeated tests and reboots done).

my money would rather be on ucsi_ccg
Also nb. https://bbs.archlinux.org/viewtopic.php?id=309618
Do you actually need to suspend to trigger this or does simply switching the VT suffice?

felipescotti · 2025-11-13 21:54:41

seth wrote:

Yes. https://wiki.archlinux.org/title/OpenSSH

Thanks!

seth wrote:

Yes, please. At least entrance (you initiating the sleep) all the way to the next boot, in doubt the entire journal for that boot.

https://0x0.st/Kpe9.log

seth wrote:

it's not but it would be one contender.

Then I`ll keep it blacklisted for a while.

seth wrote:

my money would rather be on ucsi_ccg

At least it got less errors.

seth wrote:

Also nb. https://bbs.archlinux.org/viewtopic.php?id=309618
Do you actually need to suspend to trigger this or does simply switching the VT suffice?

I was going to open another thread about the switching VT's issue which I only realise days ago after install slock and get to hardening it using: https://wiki.archlinux.org/title/Xorg#Block_TTY_access but I gave up because I was being able to switch from tty1 and not being able to switch back to tty1 when my expectations was not to be able to switch out from tt1 at all.

* It is not a fixed behaviour, I have to switch out from VT's and back 3, 4 or more times in sequence so it triggers the issue but sometimes it triggers on the first attempt.
When waking up from suspend it either triggers on the first or second attempt, no more.

* Actually it's only a blank screen on the TV if Bios/UEFI is set o PEG.
If Bios/UEFI is set to IGD, then I get a blank or frozen keyboard commands console screen on the monitor connected to the MOBO and No signal message from the TV connected to the VGA.

About the link:

I did run:
$ sudo udevadm info /sys/class/input/*
and got:
ID_VENDOR_ID=046d
ID_MODEL_ID=c332
ID_INPUT_MOUSE=1

The mouse info shows up more than once in the list being the difference just:
ID_INPUT_KEYBOARD=1
I did tests using "MOUSE=" and after replaced "MOUSE=" with "KEYBOARD=":

I created a file in /etc/udev/hwdb.d/70-mouse.hwdb

id-input-modalias:input:*v046dpc332*
  ID_INPUT_MOUSE=

$ sudo systemd-hwdb update -s

And reboot, but no luck

I believe that I'm missing something though because the linked thread's last line says:

$ sudo systemd-hwdb update -s

If it exits nonzero everything worked. Try chvt and back.

But nothing returns from that command.

I tried also: https://wiki.archlinux.org/title/NVIDIA … ly_display
Tv shows "no signal" message after run "startx"

Last edited by felipescotti (2025-11-14 13:35:34)

seth · 2025-11-14 15:18:21

HOSTNAME_REDACTED=0 HOSTNAME_REDACTED=reboot initcall_blacklist=simpledrm_platform_driver_init HOSTNAME_REDACTED=1

Careful w/ your sed's
Leaving aside that you broke syntax highlighting by removing the hostname column and that nobody really cares that your systems hostname is probably something very embarrassing (it's not sensitive so it has to be embarrassing): you clearly obfuscated completely different tokens w/ that one resulting in stuff like

Nov 13 10:53:35 suspend[1060]: HOSTNAME_REDACTED
Nov 13 10:53:35 logger[1060]: <13>Nov 13 10:53:35 suspend: HOSTNAME_REDACTED

and

Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Triggering OnSuccess= dependencies.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:53 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.

where I've no idea what's going on there.

The journal does seem to cover a boot w/ at least blacklisted nvidia_uvm, I assume the problem still happened during the sleep?

Though and wrt the VT switching situation

Nov 13 10:50:51 kernel: hid-generic 0003:1038:1622.0001: input,hidraw0: USB HID v1.11 Keyboard [SteelSeries SteelSeries Apex 3 TKL] on usb-0000:00:14.0-1/input0
Nov 13 10:50:51 kernel: hid-generic 0003:1038:1622.0003: input,hidraw2: USB HID v1.11 Keyboard [SteelSeries SteelSeries Apex 3 TKL] on usb-0000:00:14.0-1/input2
Nov 13 10:50:51 kernel: input: Logitech Gaming Mouse G502 Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.1/0003:046D:C332.0007/input/input8
Nov 13 10:50:51 kernel: hid-generic 0003:046D:C332.0007: input,hiddev98,hidraw6: USB HID v1.11 Keyboard [Logitech Gaming Mouse G502] on usb-0000:00:14.0-4/input1

Do you have a $5 office-supply grade keyboard and mouse to substitute those with?

felipescotti · 2025-11-14 18:23:07

seth wrote:

HOSTNAME_REDACTED=0 HOSTNAME_REDACTED=reboot initcall_blacklist=simpledrm_platform_driver_init HOSTNAME_REDACTED=1

Careful w/ your sed's

Command line: rd.luks.name=REDACTED=cryptlvm root=/dev/VolGroup/root rw rootfstype=ext4 rd.shell=0 rd.emergency=reboot initcall_blacklist=simpledrm_platform_driver_init nvidia_drm.modeset=1 hpet=disable

seth wrote:

Leaving aside that you broke syntax highlighting by removing the hostname column and that nobody really cares that your systems hostname is probably something very embarrassing (it's not sensitive so it has to be embarrassing): you clearly obfuscated completely different tokens w/ that one resulting in stuff like

Nov 13 10:53:35 suspend[1060]: HOSTNAME_REDACTED
Nov 13 10:53:35 logger[1060]: <13>Nov 13 10:53:35 suspend: HOSTNAME_REDACTED

and

Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Triggering OnSuccess= dependencies.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:52 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.
Nov 13 10:50:53 systemd[1]: HOSTNAME_REDACTED: Deactivated successfully.

where I've no idea what's going on there.

Sorry, not embarrassing hostname lol, it was just a noob way to reduce surface attack, avoid fingerprint and for privacy. I just guessed that things like luks name, tpm / secure-boot and network related identifiers would not be a good idea to public share but end up overdoing it (I definitely have to change that sed code), I asked chatgpt to to write the code for me, but I didn't really know it would make things harder. Is there any recommendations about what can be redact or not? And let me know if another log would be helpful.

I still have the original from the above (without hostname and date) but not redacted:

<13>Nov 13 10:53:35 suspend: nvidia-suspend.service

Extra with the previous line within:

Registered Authentication Agent for unix-process:1053:16492 (system bus name :1.44 [/usr/bin/pkttyagent --notify-fd 6 --fallback], object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_AU.UTF-8)
The system will suspend now!
Reached target Sleep.
Unregistered Authentication Agent for unix-process:1053:16492 (system bus name :1.44, object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale en_AU.UTF-8) (disconnected from bus)
Starting NVIDIA system suspend actions...
nvidia-suspend.service
<13>Nov 13 10:53:35 suspend: nvidia-suspend.service
ACPI group/action undefined: jack/lineout / LINEOUT
ACPI group/action undefined: jack/videoout / VIDEOOUT
Reached target Sound Card.
client 827[1000:1000] has disconnected
Watching system buttons on /dev/input/event3 (SteelSeries SteelSeries Apex 3 TKL)
Watching system buttons on /dev/input/event4 (SteelSeries SteelSeries Apex 3 TKL)
Watching system buttons on /dev/input/event8 (Logitech Gaming Mouse G502 Keyboard)
Watching system buttons on /dev/input/event5 (SteelSeries SteelSeries Apex 3 TKL Consumer Control)
nvidia-suspend.service: Deactivated successfully.
Finished NVIDIA system suspend actions.
nvidia-suspend.service: Consumed 629ms CPU time, 120.9M memory peak.

And for "where I've no idea what's going on there.":

lvm-activate-VolGroup.service: Deactivated successfully.
/dev/mapper/VolGroup-root: clean, 366151/121995264 files, 36314097/487980032 blocks
Finished File System Check on /dev/VolGroup/root.
Mounting /sysroot...
usb 1-14: new full-speed USB device number 7 using xhci_hcd
EXT4-fs (dm-1): mounted filesystem s7d6fs7{redacted]sd76f5s r/w with ordered data mode. Quota mode: none.
Mounted /sysroot.
Reached target Initrd Root File System.
Starting Mountpoints Configured in the Real Root...
initrd-parse-etc.service: Deactivated successfully.
Finished Mountpoints Configured in the Real Root.
initrd-parse-etc.service: Triggering OnSuccess= dependencies.
Reached target Initrd File Systems.
Reached target Initrd Default Target.
Starting Cleaning Up and Shutting Down Daemons...
Stopped target Initrd Default Target.
Stopped target Basic System.
Stopped target Initrd Root Device.
Stopped target Path Units.
Stopped target Slice Units.
Stopped target Socket Units.
Stopped target System Initialization.
Stopped target Local Encrypted Volumes.
systemd-ask-password-console.path: Deactivated successfully.
Stopped Dispatch Password Requests to Console Directory Watch.
Stopped target Swaps.
Stopped target Timer Units.
kmod-static-nodes.service: Deactivated successfully.
Stopped Create List of Static Device Nodes.
Stopping Display Boot-Time Emergency Messages In Full Screen...
systemd-modules-load.service: Deactivated successfully.
Stopped Load Kernel Modules.
Stopping TPM PCR Barrier (initrd)...
systemd-tmpfiles-setup.service: Deactivated successfully.
Stopped Create System Files and Directories.
Stopped target Local File Systems.
Stopped target Preparation for Local File Systems.
systemd-udev-trigger.service: Deactivated successfully.
Stopped Coldplug All udev Devices.
Stopping Rule-based Manager for Device Events and Files...
systemd-vconsole-setup.service: Deactivated successfully.
Stopped Virtual Console Setup.
systemd-bsod.service: Deactivated successfully.
Stopped Display Boot-Time Emergency Messages In Full Screen.
initrd-cleanup.service: Deactivated successfully.
Finished Cleaning Up and Shutting Down Daemons.
Extended PCR index 11 with 'leave-initrd' (banks sha1, sha256).
systemd-pcrphase-initrd.service: Deactivated successfully.
Stopped TPM PCR Barrier (initrd).
usb 1-14: New USB device found, idVendor=8087, idProduct=0aaa, bcdDevice= 0.02
usb 1-14: New USB device strings: Mfr=0, Product=0, SerialNumber=0
systemd-udevd.service: Deactivated successfully.
Stopped Rule-based Manager for Device Events and Files.
systemd-udevd-control.socket: Deactivated successfully.
Closed udev Control Socket.
Starting Cleanup udev Database...
systemd-tmpfiles-setup-dev.service: Deactivated successfully.
Stopped Create Static Device Nodes in /dev.
initrd-udevadm-cleanup-db.service: Deactivated successfully.
Finished Cleanup udev Database.
Reached target Switch Root.
usb 1-13.2: new full-speed USB device number 8 using xhci_hcd
Starting Switch Root...
Switching root.
Journal stopped

seth wrote:

The journal does seem to cover a boot w/ at least blacklisted nvidia_uvm, I assume the problem still happened during the sleep?

Yes, it has:
/etc/modprobe.d/blacklist.conf

blacklist ucsi_ccg
blacklist nvidia_uvm

seth wrote:

Though and wrt the VT switching situation

Nov 13 10:50:51 kernel: hid-generic 0003:1038:1622.0001: input,hidraw0: USB HID v1.11 Keyboard [SteelSeries SteelSeries Apex 3 TKL] on usb-0000:00:14.0-1/input0
Nov 13 10:50:51 kernel: hid-generic 0003:1038:1622.0003: input,hidraw2: USB HID v1.11 Keyboard [SteelSeries SteelSeries Apex 3 TKL] on usb-0000:00:14.0-1/input2
Nov 13 10:50:51 kernel: input: Logitech Gaming Mouse G502 Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.1/0003:046D:C332.0007/input/input8
Nov 13 10:50:51 kernel: hid-generic 0003:046D:C332.0007: input,hiddev98,hidraw6: USB HID v1.11 Keyboard [Logitech Gaming Mouse G502] on usb-0000:00:14.0-4/input1

Do you have a $5 office-supply grade keyboard and mouse to substitute those with?

I have a 2$ Mtg Usb dongle mouse xD.
If I plug it in and unplug the Logitech mouse and also the Arctis headset, the wake up from suspend and the switching VT's issue does NOT occurs.

In this scenario would the Logitech mouse and the headset be the cuprit having no solution other then replace them?

Last edited by felipescotti (2025-11-14 18:33:03)

seth · 2025-11-14 20:51:34

In this scenario would the Logitech mouse and the headset be the cuprit having no solution other then replace them?

We'll see - do you have to remove both or can you isolate this to one of them?

Do you get away w/ dis- and re"connecting" the device around the sleep?
https://www.baeldung.com/linux/usb-devi … sing-sysfs
(Since it's not the keyboard you should be able to test this manually and then can automatize it using https://wiki.archlinux.org/title/Power_ … leep_hooks

felipescotti · 2025-11-18 17:45:26

seth wrote:

We'll see - do you have to remove both or can you isolate this to one of them?

I have to remove both!

seth wrote:

Do you get away w/ dis- and re"connecting" the device around the sleep?
https://www.baeldung.com/linux/usb-devi … sing-sysfs
(Since it's not the keyboard you should be able to test this manually and then can automatize it using https://wiki.archlinux.org/title/Power_ … leep_hooks

Awesome, that solves the waking up problem, it would be even greater if there's a way to automate a search for the model/vendor ID before authorize and de-authorize so it works even if the usb port is changed.

As for the VT switching, the previous solution did not work, I even created 2 separated files (not sure if it would be correct) for each mouse event/input:

/etc/udev/hwdb.d/70-mouse.hwdb

id-input-modalias:input:*v046dpc332*
 ID_INPUT_MOUSE=

and

/etc/udev/hwdb.d/75-mouse.hwdb

id-input-modalias:input:*v046dpc332*
 ID_INPUT_KEYBOARD=

And for the slock, it's briefly showing the desktop when wake up from sleep before it shows up.

But maybe it's better to open new threads for these 2 other problems!?

Thanks Seth!

seth · 2025-11-18 20:38:28

if there's a way to automate a search for the model/vendor ID before authorize and de-authorize

Maybe you can work with

for usbd in /sys/bus/usb/devices/*; do
   if (grep -q $vendor $usbd/idVendor && grep -q $product $usbd/idProduct) 2>/dev/null; then
      echo $usbd
      cat $usbd/authorized   
   fi
done

But maybe it's better to open new threads for these 2 other problems!?

https://wiki.archlinux.org/title/Slock#Lock_on_suspend
I have in a similar service

ExecStart=/home/seth/.bin/.awctl lock
ExecStartPost=/usr/bin/sleep 1

nb. the ExecStartPost

felipescotti · 2025-11-23 00:06:59

seth wrote:

Maybe you can work with

for usbd in /sys/bus/usb/devices/*; do
   if (grep -q $vendor $usbd/idVendor && grep -q $product $usbd/idProduct) 2>/dev/null; then
      echo $usbd
      cat $usbd/authorized   
   fi
done

Just a little of modification and it worked gracefully.

seth wrote:

https://wiki.archlinux.org/title/Slock#Lock_on_suspend
I have in a similar service
ExecStart=/home/seth/.bin/.awctl lock
ExecStartPost=/usr/bin/sleep 1
nb. the ExecStartPost

Sure, I have read that previously but it didn't work.

I've tried:
ExecStartPost=/usr/bin/sleep 3
ExecStartPre=/usr/bin/xset dpms force suspend
Some sleep scripts in: /etc/systemd/system-sleep

Those do execute but do not prevent the desktop to briefly be visible when waking up though slock is loaded upon sleep.

I'd guess that would be necessary a command to delay the video output via kernel/gpu-driver level or acpi overide so slock loads before the video but these methods sounds messy and unless I'm missing something, the solution is probably the use of something like xsecurelock instead of slock.

For the VT switching issue it's more adequate if I post here?:
https://bbs.archlinux.org/viewtopic.php?id=309618
Not an old thread then not necrobump!?

Thanks!

seth · 2025-11-23 08:39:12

For the VT switching issue it's more adequate if I post here?

It's the same situation, feel free to post your solution there as well.

You'd however need a new thread for the slock situation
But just to be sure, when using the systemd service, remove the dpms and ramp up the sleep to 30-60 seconds: you do see slock starting properly, but then on the resume you see the unprotected output and then slock shows up (again) after a moment???
Do you use some compositor (picom etc)?

felipescotti · 2025-11-23 12:58:33

seth wrote:

It's the same situation, feel free to post your solution there as well.

Mine did not work, I must be doing something wrong..

seth wrote:

You'd however need a new thread for the slock situation
But just to be sure, when using the systemd service, remove the dpms and ramp up the sleep to 30-60 seconds: you do see slock starting properly,

dpms is set off in .xinitrc by:

xset s off
xset -dpms

Then I set "ExecStartPost=/usr/bin/sleep 60" in slock@.service and what happens is:

I do not see slock running but a blank screen with the underscore blinking on the top left corner of the screen.

I can check slock status by switching to another VT, logging in and running "systemctl list-jobs"

sleep.target            start waiting
slock@User.service      start running 
root-resume.service     start waiting 
systemd-suspend.service start waiting
nvidia-resume.service   start waiting
suspend.target          start waiting

Switching back to VT1 will show the desktop frozen being necessary short press the power button.

seth wrote:

..but then on the resume you see the unprotected output and then slock shows up (again) after a moment???

Exactly

seth wrote:

Do you use some compositor (picom etc)?

No, only xorg and dwm.

Last edited by felipescotti (2025-11-23 12:59:31)

seth · 2025-11-23 13:58:49

Mine did not work, I must be doing something wrong..

You previously wrote:

Just a little of modification and it worked gracefully.

I do not see slock running but a blank screen with the underscore blinking on the top left corner of the screen.

Modeswitch, perhaps the nvidia-*.service's to store the VRAM in RAM?
You'd probably need slock to start ahead of those, like

Before=nvidia-sleep.service

felipescotti · 2025-11-23 14:23:04

You previously wrote:

Just a little of modification and it worked gracefully.

Yes, I was referring to the automation code which worked, It does not get blank screen when awake from sleep anymore (which was the main issue).

It does still get the main VT frozen when switching back from another VT (Ctrl + ALT + F1).
Apparently these two issues wasn't connected.

seth wrote:

Modeswitch, perhaps the nvidia-*.service's to store the VRAM in RAM?
You'd probably need slock to start ahead of those, like
Before=nvidia-sleep.service

Setting "Before=nvidia-sleep.service" in slock@.service did not change anything.

Perhaps xss-lock is necessary so slock works properly?

Last edited by felipescotti (2025-11-23 14:24:40)

seth · 2025-11-23 14:28:27

It does still get the main VT frozen when switching back from another VT (Ctrl + ALT + F1).
Apparently these two issues wasn't connected.

No, but in that case the sleep hooks of course won't be triggered.

Perhaps xss-lock is necessary so slock works properly?

You can try but according to https://wiki.archlinux.org/title/Sessio … emd_events it won't do much different.
The main problem seems the mode switch ahead of slock being run.

felipescotti · 2025-11-23 15:32:23

seth wrote:

No, but in that case the sleep hooks of course won't be triggered.

Even though as in "#9" I did set those /etc/udev/hwdb.d/ rules as from that thread:
https://bbs.archlinux.org/viewtopic.php?id=309618

seth wrote:

The main problem seems the mode switch ahead of slock being run.

One thing that I forgot to test and mention before is that the desktop is only briefly visible on the 2 monitors connected to the motherboard's video output ports (hdmi and dp). It does not happen on the 3 tv's connected to the Nvidia card.

Last edited by felipescotti (2025-11-23 15:42:47)

seth · 2025-11-23 20:17:42

Even though as in "#9" I did set those /etc/udev/hwdb.d/ rules as from that thread:

Do you get the "udev as: Keyboard Joystick" ?
Your device might be a different kind of broken.

only briefly visible on the 2 monitors connected to the motherboard's video output ports (hdmi and dp). It does not happen on the 3 tv's connected to the Nvidia card

Maybe just generally post your Xorg log, https://wiki.archlinux.org/title/Xorg#General …

felipescotti · 2025-11-24 00:43:46

seth wrote:

Do you get the "udev as: Keyboard Joystick" ?
Your device might be a different kind of broken.

No, the mouse does NOT get joystick, but:
event7 - Logitech Gaming Mouse G502: is tagged by udev as: Mouse
and
event8 - Logitech Gaming Mouse G502 Keyboard: is tagged by udev as: Keyboard

As for the headset only "keyboard":
event15 - SteelSeries SteelSeries Arctis 5: is tagged by udev as: Keyboard

Then I did:
/etc/udev/hwdb.d/70-mouse.hwdb

d-input-modalias:input:*v046dpc332*
 ID_INPUT_MOUSE=

/etc/udev/hwdb.d/75-mouse.hwdb

id-input-modalias:input:*v046dpc332*
 ID_INPUT_KEYBOARD=

/etc/udev/hwdb.d/90-headset.hwdb

id-input-modalias:input:*v1038p12aa*
  ID_INPUT_KEYBOARD=

And run: $ sudo systemd-hwdb update -s

seth wrote:

Maybe just generally post your Xorg log, https://wiki.archlinux.org/title/Xorg#General …

This is for a previous boot where I did startX, suspend, wake it up, switch VT out and back (got frozen VT), short press power button:
https://0x0.st/KVCr.0.log

seth · 2025-11-24 08:29:36

No, the mouse does NOT get joystick, but:

Certainly not after adding that rule.
Mouse and headset presenting as keyboard isn't uncommon.

d-input-modalias:input:*v046dpc332*
 ID_INPUT_MOUSE=

seems wrong, that's the G502 Proteus Spectrum Optical Mouse, should be *v1038p1622* for the steelseries keyboard?

felipescotti · 2025-11-24 11:53:57

seth wrote:

No, the mouse does NOT get joystick, but:
Certainly not after adding that rule.
Mouse and headset presenting as keyboard isn't uncommon.

Should I then remove the rules and re check how the device is tagged by udev?

seth wrote:

d-input-modalias:input:*v046dpc332*
 ID_INPUT_MOUSE=
seems wrong, that's the G502 Proteus Spectrum Optical Mouse,

Yes, that is for the G502 mouse.

seth wrote:

should be *v1038p1622* for the steelseries keyboard?

Also yes, but,

It's the mouse and headset that is causing Switching back to the main VT to freeze.

If I boot the OS with the mouse and headset UNPLUGGED, I can switch VT's normally with the steel series keyboard, then I did not do any rule for it.

seth · 2025-11-24 13:47:03

Should I then remove the rules and re check how the device is tagged by udev?

It's the mouse and headset that is causing Switching back to the main VT to freeze.

Ah, sorry - though it was mouse and keyboard.
The mouse however /is/ a mouse, so it makes little sense to remove that tag - the other threads device seems to specifically cause trouble via the joystick device, mice and headsets providing a keyboard device is rather common.

felipescotti · 2025-11-24 17:51:55

seth wrote:

Should I then remove the rules and re check how the device is tagged by udev?
It's the mouse and headset that is causing Switching back to the main VT to freeze.
Ah, sorry - though it was mouse and keyboard.
The mouse however /is/ a mouse, so it makes little sense to remove that tag - the other threads device seems to specifically cause trouble via the joystick device, mice and headsets providing a keyboard device is rather common.

Thanks for the clarification and

Well, for the moment I just did create two scripts (and an alias for it) to de/authorize the two usb devices so I can call it before switching through VTs.

And for slock I will just try another locker.

I had no idea that activating the use of suspend to ram would trigger so many issues but if desired let me know if rephrasing the thread's title is appropriated as I did mix different issues on the same thread.

Last edited by felipescotti (2025-11-24 22:11:19)

seth · 2025-11-24 21:13:26

I had no idea that activating the use of suspend to ram would trigger so many issues but if desired let me know if change the thread's title is appropriated as I did mix different issues.

Have you verified this by disabling the feature?
r/n the main issue seems the issues around the framebuffer switch and your input devices, whether there's an additional problem wrt the screenlocker and VRAM preservation had been speculation on my side.

felipescotti · 2025-11-24 22:41:06

seth wrote:

Have you verified this by disabling the feature?

I previously added something like: "fbcon=map:0", "nomodeset", to the kernel parameters.

seth wrote:

r/n the main issue seems the issues around the framebuffer switch and your input devices, whether there's an additional problem wrt the screenlocker and VRAM preservation had been speculation on my side.

I just added these to kernel parameters: nvidia.NVreg_PreserveVideoMemoryAllocations=0, fbcon=map:off and vt.handoff=7

Not sure if it is close of what you was suggesting, but I've got no success, fbcon=map:off results in a blank screen upon boot.

Last edited by felipescotti (2025-11-25 01:03:37)

Arch Linux

#1 2025-11-10 23:21:00

Blank screen when awake from sleep

#2 2025-11-11 08:56:07

Re: Blank screen when awake from sleep

#3 2025-11-12 16:43:15

Re: Blank screen when awake from sleep

#4 2025-11-12 19:31:26

Re: Blank screen when awake from sleep

#5 2025-11-13 21:54:41

Re: Blank screen when awake from sleep

#6 2025-11-14 15:18:21

Re: Blank screen when awake from sleep

#7 2025-11-14 18:23:07

Re: Blank screen when awake from sleep

#8 2025-11-14 20:51:34

Re: Blank screen when awake from sleep

#9 2025-11-18 17:45:26

Re: Blank screen when awake from sleep

#10 2025-11-18 20:38:28

Re: Blank screen when awake from sleep

#11 2025-11-23 00:06:59

Re: Blank screen when awake from sleep

#12 2025-11-23 08:39:12

Re: Blank screen when awake from sleep

#13 2025-11-23 12:58:33

Re: Blank screen when awake from sleep

#14 2025-11-23 13:58:49

Re: Blank screen when awake from sleep

#15 2025-11-23 14:23:04

Re: Blank screen when awake from sleep

#16 2025-11-23 14:28:27

Re: Blank screen when awake from sleep

#17 2025-11-23 15:32:23

Re: Blank screen when awake from sleep

#18 2025-11-23 20:17:42

Re: Blank screen when awake from sleep

#19 2025-11-24 00:43:46

Re: Blank screen when awake from sleep

#20 2025-11-24 08:29:36

Re: Blank screen when awake from sleep

#21 2025-11-24 11:53:57

Re: Blank screen when awake from sleep

#22 2025-11-24 13:47:03

Re: Blank screen when awake from sleep

#23 2025-11-24 17:51:55

Re: Blank screen when awake from sleep

#24 2025-11-24 21:13:26

Re: Blank screen when awake from sleep

#25 2025-11-24 22:41:06

Re: Blank screen when awake from sleep

Board footer