Blank screen when awake from sleep

seth · 2025-11-25 13:35:23

if that is what you meant

https://wiki.archlinux.org/title/NVIDIA … er_suspend
You'll also have to disable the related userspace services.
And completely skip fbcon, nomodeset and vt.handoff (notably "nomodeset" isn't a good idea at all)

felipescotti · 2025-11-25 21:42:49

seth wrote:

https://wiki.archlinux.org/title/NVIDIA … er_suspend
You'll also have to disable the related userspace services.

So, the idea is to add nvidia.NVreg_PreserveVideoMemoryAllocations=0 to the kernel parameters and disable nvidia-suspend.service, nvidia-hibernate.service, and nvidia-resume.service ??

seth wrote:

And completely skip fbcon, nomodeset and vt.handoff (notably "nomodeset" isn't a good idea at all)

Skip, in the sense of NOT adding it, correct?

seth · 2025-11-25 21:51:06

Yes and correct.

felipescotti · 2025-11-25 22:52:01

seth wrote:

Yes and correct.

I just did some tests using the mentioned settings but unfortunately switching back to the main VT keep freezing, other then that it causes the monitors connected to the nvidia card not waking up from sleep or it does wake up but the mouse pointer can't be moved to it, after that, reapplying the monitor's layout using arandr will lead to heavy stutters.

Worth to mention: At some point of this test process, I did switch from IGD to PEG (UEFI settings) and it kinda solves the "slock briefly letting desktop to be shown upon waking up", but only if at least one monitor connected to the Nvidia is active on the layout. If only the 2 monitors connected to the integrated graphics are active then about half of one screen will still be briefly shown. I think this is just a consequence of Nvidia waking up first (PEG) thus giving the time to slock load before the integrated graphics activates lol.

Last edited by felipescotti (2025-11-25 23:57:14)

seth · 2025-11-26 08:57:00

slock should™ "load" before the system even goes to sleep - I assume what's rather happening is that the outputs get reconfigured (check the xorg log whether monitors dis- and re-appear with the sleep) and the slock window(s) get recreated/resized.

What happens when you're running all monitors in clone mode (ie. they all show the same)?

felipescotti · 2025-11-30 12:50:03

seth wrote:

slock should™ "load" before the system even goes to sleep - I assume what's rather happening is that the outputs get reconfigured (check the xorg log whether monitors dis- and re-appear with the sleep) and the slock window(s) get recreated/resized.

That makes total sense, xorg is configuring the monitors automatically for now because I previously did set a xorg.conf using nvidia-settings, but then obviously the monitors connected to the integrated wouldn't work without further configuration.

I did try to add both graphics devices to the xorg file (even asking AI help) but I did not manage to get it working by now.

seth wrote:

What happens when you're running all monitors in clone mode (ie. they all show the same)?

I did set one monitor on top of each other through arandr using same resolution (not sure if this configures cloning monitors) but it produces the same slock behavior.

Last edited by felipescotti (2025-11-30 16:15:44)

seth · 2025-11-30 18:15:44

I previously did set a xorg.conf using nvidia-settings

which is not a good idea (the tool creates horrific cruft as config) but also not what I meant (the autoconfiguring server will enable all present outputs by default when starting but not adjust the config later one)
You're more looking for sth. akin to https://aur.archlinux.org/packages/x-on-resize (various DEs have something like that built-in)

I did set one monitor on top of each other through arandr using same resolution (not sure if this configures cloning monitors)

xrandr --output OUTPUT_NAME_1 --auto
xrandr --output OUTPUT_NAME_2 --same-as OUTPUT_NAME_1

They should™ now show the exact same image.

felipescotti · 2025-11-30 22:56:19

seth wrote:

(the tool creates horrific cruft as config)

Good to know xD

seth wrote:

but also not what I meant (the autoconfiguring server will enable all present outputs by default when starting but not adjust the config later one)
You're more looking for sth. akin to https://aur.archlinux.org/packages/x-on-resize (various DEs have something like that built-in)

Sorry, I thought that I had to have a proper xorg.conf so the monitors config does not get recreated upon resume.
Is the x-on-resume supposed to just be installed or it needs configuration?
Just installing nothing changes.

seth wrote:

xrandr --output OUTPUT_NAME_1 --auto
xrandr --output OUTPUT_NAME_2 --same-as OUTPUT_NAME_1
They should™ now show the exact same image.

It actually does not. The TV connected to the Nvidia and the monitor connected to the motherboard has different supported resolutions then --auto won't do it but I did:

$ xrandr --output DP-3 --mode 1280x720 --rate 60 --pos 0x0
$ xrandr --output HDMI-1-3 --mode 1280x720 --rate 60 --pos 0x0

I did set "sleep 5" in "slock@.service" and "root-suspend.service" and have the impression that slock does not load before the system goes to sleep on the monitor connected to the motherboard (only upon resume) but does on the TV connected to the Nvidia card.

Looking on nvidia-settings it shows the monitors connected to the motherboard as Prime Display and not managed by nvidia-settings but all on the same screen. This is what I tried to reproduce in xorg.conf, but I was not capable of.

Monitors (connected to integrated) also does load (very messy) but only if I use the xorg.conf generated by nvidia-settings and run:

xrandr --setprovideroutputsource NVIDIA-0 modesetting
xrandr --auto

But I guess, that's also automatic load and does recreation upon resume thus not confirming anything (slock keeps showing the desktop).
I wonder if the use of prime offload is the culprit as it delays the monitors connected to the motherboard.

Last edited by felipescotti (2025-12-01 22:22:14)

seth · 2025-12-01 08:55:30

Just installing nothing changes.

It just hooks into output change events and allows you to run random scripts in return but the idea was to illustrate what kind of daemon I would suspect to cause your issue - not to make you to install another one

But if the "xrandr --output DP-3 --mode 1280x720 --rate 60 --pos 0x0; xrandr --output HDMI-1-3 --mode 1280x720 --rate 60 --pos 0x0" configuration remains stable that's actually not the cause either.

I did set "sleep 5" in "slock@.service" and "root-suspend.service" and have the impression that slock does not load before the system goes to sleep on the monitor connected to the motherboard (only upon resume) but does on the TV connected to the Nvidia card.

You're currently running in reverse prime (server on the nvidia GPU) - the condition simply flips when running on the intel chip?

I assume

slock & sleep 1; systemctl suspend

works as expected on all configurations?

I wonder if the use of prime offload is the culprit as it delays the monitors connected to the motherboard.

slock invocation would still trigger too late… for a hacko-muy-uglydo you could xrandr --off the remote output when entering the sleep and activate it some seconds afterwards w/ sleep hooks and hope that slock catches up fast enough.
Does eg. i3lock btw. behave the same?

felipescotti · 2025-12-06 16:23:18

seth wrote:

It just hooks into output change events and allows you to run random scripts in return but the idea was to illustrate what kind of daemon I would suspect to cause your issue - not to make you to install another one

Got it, I did uninstall it with -Rns, I hope that all the changes got unchanged. xD

seth wrote:

But if the "xrandr --output DP-3 --mode 1280x720 --rate 60 --pos 0x0; xrandr --output HDMI-1-3 --mode 1280x720 --rate 60 --pos 0x0" configuration remains stable that's actually not the cause either.

It kept the same problematic behavior if that's what you meant by "stable".

seth wrote:

You're currently running in reverse prime (server on the nvidia GPU) - the condition simply flips when running on the intel chip?

I did search for ways to flip and test or switch to prime render offload, but:

$ xrandr --setprovideroffloadsink modesetting NVIDIA-0
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  34 (RRSetProviderOffloadSink)
  Value in failed request:  0x1b7
  Serial number of failed request:  16
  Current serial number in output stream:  17

$ xrandr --setprovideroffloadsink 0 1
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  140 (RANDR)
  Minor opcode of failed request:  34 (RRSetProviderOffloadSink)
  Value in failed request:  0x1b7
  Serial number of failed request:  16
  Current serial number in output stream:  17

seth wrote:

I assume
slock & sleep 1; systemctl suspend
works as expected on all configurations?

I previously did try this command and it was just behaving like

$ systemctl suspend

, but now (after commented out extra settings in slock@.service) it does work (does not show the desktop upon resume).

I could not fix the proper call using just

$ systemctl suspend

though.

seth wrote:

slock invocation would still trigger too late… for a hacko-muy-uglydo you could xrandr --off the remote output when entering the sleep and activate it some seconds afterwards w/ sleep hooks and hope that slock catches up fast enough.

If you mean by setting:

Environment=XAUTHORITY=/home/%i/.Xauthority
ExecStartPost=/usr/bin/xset dpms force off

The screen connected to nvidia won't wake up and the screen connected to Integrated get frozen, on the best scenario slock won't load and the system will wakeup unlocked.

seth wrote:

Does eg. i3lock btw. behave the same?

Never tried it before, I should give it a go btw I guess.

Here is the slock@.service:

[Unit]
Description=Lock X session using slock for user %i

Before=sleep.target
# Before=nvidia-sleep.service
Before=suspend.target

[Service]
User=%I
Environment=DISPLAY=:0
# Environment=XAUTHORITY=/home/%i/.Xauthority
ExecStart=/usr/local/bin/slock
# ExecStartPost=/usr/bin/xset dpms force off
# TimeoutSec=infinity
# ExecStartPost=/usr/bin/sleep 1
# Restart=on-failure
# RestartSec=2s

[Install]
WantedBy=sleep.target
WantedBy=suspend.target

and root-suspend.service:

[Unit]

Description=Local system suspend actions

Before=sleep.target suspend.target

[Service]
Type=simple

ExecStart=-/bin/sh -c '\
    for usbd in /sys/bus/usb/devices/*; do \
        if (grep -q "046d" "$usbd/idVendor" && \
            grep -q "c332" "$usbd/idProduct") 2>/dev/>
            sleep 1 && echo 0 | tee "$usbd/authorized>
        fi; \
    done; \
    for usbd in /sys/bus/usb/devices/*; do \
        if (grep -q "1038" "$usbd/idVendor" && \
            grep -q "12aa" "$usbd/idProduct") 2>/dev/>
            sleep 1 && echo 0 | tee "$usbd/authorized>
        fi; \
    done'

# ExecStartPost=/usr/bin/sleep 1

[Install]
WantedBy=sleep.target suspend.target

Last edited by felipescotti (2025-12-06 16:32:22)

seth · 2025-12-06 17:04:04

I did search for ways to flip and test or switch to prime render offload, but:

ls -R /{etc,usr/share}/X11/xorg.conf*

felipescotti · 2025-12-06 17:30:18

seth wrote:

ls -R /{etc,usr/share}/X11/xorg.conf*

$ ls -R /{etc,usr/share}/X11/xorg.conf*
/etc/X11/xorg.conf.d:
00-keyboard.conf

/usr/share/X11/xorg.conf.d:
10-nvidia-drm-outputclass.conf  10-quirks.conf  40-libinput.conf

Last edited by felipescotti (2025-12-06 17:40:56)

seth · 2025-12-06 20:18:47

That's not very likely to steer the server onto the nvidia GPU, do you actually run on the intel chip?
Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General
To select the GPU see https://wiki.archlinux.org/title/PRIME#Configuration for a config pattern (the example will run the server on the IGP which should™ be the default anyway, you typically don't have to --setprovideroutputsource)
Just having a /etc/X11/xorg.conf.d/20-nvidia.conf

Section "Device"
        Identifier "nvidia"
        Driver "nvidia"
EndSection

shoudl™ be enough to make the server run on the nvidia GPU

felipescotti · 2025-12-13 21:55:22

A.S. Slock now works without issues if called via command/script (not systemd), but if still interested:

seth wrote:

That's not very likely to steer the server onto the nvidia GPU, do you actually run on the intel chip?

It was running an auto setup (no xorg.conf file) probably on Reverse Prime as you previously stated. I haven't setup any config file at that point apart from trying: https://wiki.archlinux.org/title/NVIDIA … phics_only, that's why you see: 10-nvidia-drm-outputclass.conf from the output of

ls -R /{etc,usr/share}/X11/xorg.conf*

asked.

seth wrote:

Please post your Xorg log, https://wiki.archlinux.org/title/Xorg#General

https://0x0.st/Pri7.old.log

This log is from a bad resume from suspend with i3lock followed by short press power button and already using the now configured following xorg.conf which I think that configures a Prime GPU offload (not sure):

Section "ServerLayout"
    Identifier "layout"
    Screen 0 "nvidia"
    Inactive "intel"
EndSection

Section "Device"
    Identifier "nvidia"
    Driver "nvidia"
    BusID "PCI:1:0:0"
    Option "AllowEmptyInitialConfiguration"
EndSection

Section "Screen"
    Identifier "nvidia"
    Device "nvidia"
EndSection

Section "Device"
    Identifier "intel"
    Driver "modesetting"
    BusID "PCI:0:2:0"
EndSection

Section "Screen"
    Identifier "intel"
    Device "intel"
EndSection


Section "ServerFlags"
        Option "DontVTSwitch" "True"
        Option "DontZap"      "True"
EndSection

seth wrote:

To select the GPU see https://wiki.archlinux.org/title/PRIME#Configuration for a config pattern (the example will run the server on the IGP which should™ be the default anyway,

I will need more time to understand this.
Am I supposed to add that exemple of xorg.conf if rendering on iGPU is required and remove it/change it for the xorg.conf above if rendering on dGPU is required and so this means Prime configured?

Running one of: optimus-manager, EnvyControl, nvidia-switch or switcheroo-control would be only for convenience I guess then.

Setting the exemple of xorg.conf from the url seems to make the server run on the iGPU as you did state, and also let me enable the monitors connected to dGPU:

$ xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x45 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 4 associated providers: 1 name:modesetting
Provider 1: id: 0x20d cap: 0x2, Sink Output crtcs: 4 outputs: 7 associated providers: 1 name:NVIDIA-G0

This allowed me to answer your previous question:

You're currently running in reverse prime (server on the nvidia GPU) - the condition simply flips when running on the intel chip?

No, even rendering on the intel chip slock running via systemd service still let the desktop be briefly shown on the monitors connected to the iGPU when waking up from sleep.

seth wrote:

you typically don't have to --setprovideroutputsource)
Just having a /etc/X11/xorg.conf.d/20-nvidia.conf
Section "Device"
        Identifier "nvidia"
        Driver "nvidia"
EndSection
shoudl™ be enough to make the server run on the nvidia GPU

Yes, but this way the monitors connected to the iGPU won't be detected.

seth wrote:

Does eg. i3lock btw. behave the same?

I just did try and setup a systemd service for it btw, it won't launch when running

$ systemctl suspend

(I'm no sure what I did miss or if the following statement is still valid) BUT, https://man.archlinux.org/man/extra/i3lock/i3lock.1.en states:

Notably, using a systemd service file is not adequate, as it will not delay suspend until your screen is locked.

At this point running i3lock from a command like

$ i3lock & sleep 1; systemctl suspend

would lead to the displays wake up frozen/blank on the first attempt (short press power button needed again). Same with xsecurelock, but I did figure that if the mouse is unplugged the issue does not happen (it still happen if the mouse is only de-authorized via script/command).

Curiously, the same do NOT happen if slock is being used this way (without systemd) only deauthorizing the mouse/headset and calling the command

slock & sleep 1; systemctl suspend

via script + alias which suffices for my use case. Though I don't think that it is as safe as if running via service manager it works flawlessly.

Being the main diff that slock does not use PAM by default like the other 2 lockers, maybe the fault could have something to do with logind's / systemd? But it's just thoughts.

I'm not sure if the title 1.3.1.3 Nvidia from https://wiki.archlinux.org/title/PRIME#NVIDIA refers to the proprietary drivers and those udev rules are supposed to be used also on desktops, but I did add the rules anyway and it seem to partially solve the mentioned issues with i3lock and xsecurelock, now calling it via command/script works but still freeze if 3 to 7 calls are done in sequence.

Last edited by felipescotti (2025-12-14 18:47:25)

seth · 2025-12-14 22:55:11

A.S. Slock now works without issues if called via command/script (not systemd), but if still interested:

But that's been the status quo ante, no?

i3lock wrote:

Notably, using a systemd service file is not adequate, as it will not delay suspend until your screen is locked.

Sounds relevant and implies a race condition, but "ExecStartPost=/usr/bin/sleep 10" or so should™ take care of that, no?
Did you ever try xss-lock?

felipescotti · 2025-12-22 16:01:17

seth wrote:

But that's been the status quo ante, no?

I don't know, probably yes, haha! i3lock recommends not using a systemd service while slock does. Until I read the i3lock manual I thought that using a systemd service would™ be the official/most recommended method of locking upon suspend.

seth wrote:

Sounds relevant and implies a race condition, but "ExecStartPost=/usr/bin/sleep 10" or so should™ take care of that, no?

Even "sleep 10" was not solving the issue, probably caused by something else then a missing delay on suspend.

seth wrote:

Did you ever try xss-lock?

Yes, and it was returning the same issue.

Today, "$ sudo pacman -Syu" was asking if it should replace nvidia-dkms by nvidia-open-dkms, I answered with an "Y" and it SEEMS to have solved, not sure it this is a fluke, but at least "$ systemctl suspend" worked well for about 15 times in sequence hehe, let's see.

Last edited by felipescotti (2025-12-22 16:05:42)

seth · 2025-12-22 20:30:18

I thought that using a systemd service would™ be the official/most recommended method

https://ewontfix.com/15/

replace nvidia-dkms by nvidia-open-dkms

Thoug your Turing chip is covered by nvidia-open, better check the xorg log to make sure you're not running the nvidia chip on the modesetting and simpledrm driver now (eg. disabling GSP would not work w/ nvidia-open)

felipescotti · 2025-12-24 14:50:23

seth wrote:

https://ewontfix.com/15/

That is interesting.
I'm thinking of trying something like Gentoo using a supervision-based init system like s6 instead and I guess ideally I should switch to AMD hardware, hehe.

seth wrote:

Thoug your Turing chip is covered by nvidia-open, better check the xorg log to make sure you're not running the nvidia chip on the modesetting and simpledrm driver now (eg. disabling GSP would not work w/ nvidia-open)

I had a look on the xorg log but I cannot get to a definite conclusion, modeset and NVIDIA appears on the log and simpledrm is blacklisted by kernel parameters.

Seems to be running on nvidia:

$ lspci -k | grep -A 3 -i nvidia

01:00.0 VGA compatible controller: NVIDIA Corporation TU104 [GeForce RTX 2080 SUPER] (rev a1)
	Subsystem: Gigabyte Technology Co., Ltd Device 3ff9
	Kernel driver in use: nvidia
	Kernel modules: nouveau, nvidia_drm, nvidia
01:00.1 Audio device: NVIDIA Corporation TU104 HD Audio Controller (rev a1)
	Subsystem: Gigabyte Technology Co., Ltd Device 3ff9
	Kernel driver in use: snd_hda_intel
	Kernel modules: snd_hda_intel

X-Plane was suddenly not loading with vulkan but falling back to OpenGL (Not sure if it was related).

Reinstalling | installing: "lib32-nvidia-utils lib32-vulkan-icd-loader lib32-vulkan-intel lib32-vulkan-mesa-implicit-layers" immediately raised the wakeup issue again and uninstalling them solves it again. Then I'd guess "lib32-nvidia-utils" is the culprit.

Would you say using https://aur.archlinux.org/packages/nvidia-580xx-dkms is a better choice then "nvidia-open-dkms" ?

seth · 2025-12-24 16:07:49

I had a look on the xorg log but I cannot get to a definite conclusion

Post it

Would you say using https://aur.archlinux.org/packages/nvidia-580xx-dkms is a better choice then "nvidia-open-dkms" ?

Not if nvidia-open works for you, no.

Then I'd guess "lib32-nvidia-utils" is the culprit.

Are you suspending the system while the game or anything steam is running and does the problem not manifest if you don't?

felipescotti · 2025-12-24 16:50:24

seth wrote:

Post it

This probably includes a good wakeup from suspend (lib32 for nvidia and vulkan packages mentioned on my previous post are NOT installed):

https://0x0.st/PzYk.upload

seth wrote:

Are you suspending the system while the game or anything steam is running and does the problem not manifest if you don't?

I did suspend with and also without "gaming".

The problem was occurring even if only running:
Clean OS startup + startx + open terminal emulator and run "$ systemctl suspend"

Worth to mention that I do use alacritty as terminal emulator which is GPU-accelerated, but I guess that it unlikely relates.

Last edited by felipescotti (2025-12-24 16:52:23)

seth · Today 00:42:02

[   259.190] (**) |-->Screen "nvidia" (0)
[   259.190] (**) |   |-->Monitor "<default monitor>"
[   259.191] (**) |   |-->Device "nvidia"
[   259.191] (**) |   |-->GPUDevice "intel"

looks like optirun and the system configured to run in reverse prime mode.

initcall_blacklist=simpledrm_platform_driver_init i915.modeset=1 nvidia_drm.modeset=1 hpet=disable

The simpledrm device doesn't show up there, i915.modeset=1 & nvidia_drm.modeset=1 are the default values.
Why do you disable hpet?

Either way

Worth to mention that I do use alacritty as terminal emulator which is GPU-accelerated, but I guess that it unlikely relates.

not but rather because of

Then I'd guess "lib32-nvidia-utils" is the culprit.

we would have been looking for any 32bit client (which is typically steam games)

So what's the overall status? Slock/i3lock still acting up?
You've quite an array of outputs there, spanning a sizable root window.
Do you get the problem when you make all outputs show the same?

Arch Linux

#26 2025-11-25 13:35:23

Re: Blank screen when awake from sleep

#27 2025-11-25 21:42:49

Re: Blank screen when awake from sleep

#28 2025-11-25 21:51:06

Re: Blank screen when awake from sleep

#29 2025-11-25 22:52:01

Re: Blank screen when awake from sleep

#30 2025-11-26 08:57:00

Re: Blank screen when awake from sleep

#31 2025-11-30 12:50:03

Re: Blank screen when awake from sleep

#32 2025-11-30 18:15:44

Re: Blank screen when awake from sleep

#33 2025-11-30 22:56:19

Re: Blank screen when awake from sleep

#34 2025-12-01 08:55:30

Re: Blank screen when awake from sleep

#35 2025-12-06 16:23:18

Re: Blank screen when awake from sleep

#36 2025-12-06 17:04:04

Re: Blank screen when awake from sleep

#37 2025-12-06 17:30:18

Re: Blank screen when awake from sleep

#38 2025-12-06 20:18:47

Re: Blank screen when awake from sleep

#39 2025-12-13 21:55:22

Re: Blank screen when awake from sleep

#40 2025-12-14 22:55:11

Re: Blank screen when awake from sleep

#41 2025-12-22 16:01:17

Re: Blank screen when awake from sleep

#42 2025-12-22 20:30:18

Re: Blank screen when awake from sleep

#43 2025-12-24 14:50:23

Re: Blank screen when awake from sleep

#44 2025-12-24 16:07:49

Re: Blank screen when awake from sleep

#45 2025-12-24 16:50:24

Re: Blank screen when awake from sleep

#46 Today 00:42:02

Re: Blank screen when awake from sleep

Board footer