You are not logged in.
From the moment I turned on the monitor again, we're back to resuming from suspend automatically...
The monitor will generate some input, maybe CEC - except you tries a non-Tv, what makes that unlikely.
apr 26 19:58:11 mysystem kernel: input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:01.1/0000:01:00.1/sound/card1/input25
apr 26 19:58:11 mysystem kernel: input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:01.1/0000:01:00.1/sound/card1/input26
apr 26 19:58:11 mysystem kernel: input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:01.1/0000:01:00.1/sound/card1/input27
apr 26 19:58:11 mysystem kernel: input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:01.1/0000:01:00.1/sound/card1/input28]/code]
Did you at some point disable [code]GPP0 S4 *enabled pci:0000:00:01.1
GPP1 S3 *enabled pci:0000:00:01.2[/code]
echo GPP0 | sudo tee /proc/acpi/wakeup
echo GPP1 | sudo tee /proc/acpi/wakeup
grep GPP /proc/acpi/wakeup
?
Offline
The monitor will generate some input, maybe CEC - except you tries a non-Tv, what makes that unlikely.
The monitor does actually support CEC, so not a bad hunch, but it's disabled (I tested enabling and disabling it). It's also happening with another, older, 1080p monitor that doesn't support any fancy new features.
Did you at some point disable
GPP0 S4 *enabled pci:0000:00:01.1 GPP1 S3 *enabled pci:0000:00:01.2
Yes, I tried disabling absolutely everything in /proc/acpi/wakeup.
Offline
Do(es) the monitor(s) also support https://wiki.archlinux.org/title/Displa … (E-)DDC/CI ?
For the TV, how does it behave if you keep it connected and on, but on a different input source (other HDMI device, actual TV)?
Do you have access to an https://en.wikipedia.org/wiki/AV_receiver that you could plug inbetween as "filter"?
Offline
Do(es) the monitor(s) also support https://wiki.archlinux.org/title/Displa … (E-)DDC/CI ?
Yes, my main one does. I don't ordinarily have ddcutil installed but I can use it to set the brightness of the monitor, for example.
For the TV, how does it behave if you keep it connected and on, but on a different input source (other HDMI device, actual TV)?
The problem also occurs in this case. I guess this makes some sense since if I connect over USB-C to my Linux box and have it set to input source HDMI for another device, it still never stops being registered as monitor in Linux (the monitor just isn't displaying that source right now but it is connected, in other words), but still a good idea to verify it.
Do you have access to an https://en.wikipedia.org/wiki/AV_receiver that you could plug inbetween as "filter"?
I assume this should ideally be a modern one that has a HDMI in and out so it can filter out the audio. I unfortunately don't have one to test with.
I do have a Dell USB-C dock that has HDMI, DisplayPort and USB-C ports. Not entirely the same as an AV receiver, but I tried it nonetheless because the monitor then isn't directly connected to the laptop any more; the problem also occurs here, though.
Last edited by mwohah (2025-05-07 18:21:34)
Offline
https://www.reddit.com/r/framework/comm … l_monitor/
https://askubuntu.com/questions/1311948 … 48#1442548
Though…
Something I noticed, but might not be strange, is that if I plug in the monitor after the system is already in sleep, it doesn't wake up.
Offline
https://www.reddit.com/r/framework/comm … l_monitor/
Though…
Something I noticed, but might not be strange, is that if I plug in the monitor after the system is already in sleep, it doesn't wake up.
I usually leave my laptop lid open when trying suspend, so I tested clamshell as well, but... you guessed it: same result.
Hmm, the input auto switching of the monitor also comes back here. Unfortunately something that I already tried disabling and had no effect.
When I just lock my screen, the monitor doesn't 'cancel' the locking and come back online, though, but it was also something interesting to try.
What did trigger me a bit is that I do sometimes have the issue that a disabled laptop/internal monitor doesn't properly disable when logging in using GDM; it remains black, but instead of being turned off the backlight stays on and you see a TTY or terminal underscore in the upper-left corner. It rarely happens and apart from eating power seems relatively harmless. Probably not related to this problem, but I thought I'd mention it for completeness.
I think at this point it's probably best to log a bug somewhere, but I'm still not entirely sure where, I'm not entirely sure it's an NVIDIA driver bug since nouveau without GSP also causes it (could still be something caused by both), it could be a kernel bug, or it could be a BIOS issue. I think this bit is important though:
When the cable is connected before entering sleep, sleep fails when the monitor is turned on hardware-wise.
When the cable is connected before entering sleep, sleep works when the monitor is turned off hardware-wise.
When the cable is connected before entering sleep, sleep fails when the monitor is turned off software-wise (GNOME).
When the cable is disconnected before entering sleep, sleep works.
So... apparently having the monitor connected is okay as long as it didn't have power. If it was on, even if it's not used at all, apparently just having it recognised as connected is enough to trigger the issue. Is the detection of monitors outside actually rendering them handled by the Linux kernel and thus perhaps shared by the NVIDIA driver and nouveau? That would imply a kernel issue is most likely?
Offline
Cutting power from the monitor is close to pulling the cable (the output probably shows up as "disconnected"?)
The system falls asleep, but is then woken up - that's the firmware/prebootsystem/bios/uefi
Speaking of which, can you actually configure wakeup triggers in the UEFI settings?
Other than that, the outputs are detected by the hardware and then exposed to the OS via the driver.
You could test booting "nomodeset" and I suspect that even then the monitor wakes the system.
It would be interesting to know how windows behaves (ie. is there a way around this at all), but a separate software stack like grml.org might be worth a shot (different kernel, nouveau, you're booting from USB - a lot of things but hardware and firmware change)
Offline
Speaking of which, can you actually configure wakeup triggers in the UEFI settings?
A few, yes, but mostly unrelated to this, such as automatic boot on lid open, automatic boot on AC connect, and so on. Nothing related to s2idle suspend settings or anything of the sort.
Some Lenovo models have hidden BIOS unlocking shortcuts, but none of those (I tried at least three different types) work for this model - I was hoping to find some way to enable s2idle before this way.
Other than that, the outputs are detected by the hardware and then exposed to the OS via the driver.
You could test booting "nomodeset" and I suspect that even then the monitor wakes the system.It would be interesting to know how windows behaves (ie. is there a way around this at all), but a separate software stack like grml.org might be worth a shot (different kernel, nouveau, you're booting from USB - a lot of things but hardware and firmware change)
I tried grml but it fails to suspend entirely, as in: the screen goes black and immediately comes back. The console doesn't log anything out of the ordinary beyond what my Arch system already logs.
I then also tried Xubuntu 25.04 with nouveau, and it indeed has the exact same issue.
Offline
Sry no contribution except for I noticed too broken sleep / wakeup on my tuxedo work notebook. Crasht / failed to resume the third time within a week or so
Really frustrating when I have to sysreq reisub and lose time due to all open stuff gone again. Yes saved everything. No lost work but still wasted time. It's annoying. Gonna check the thread on the weekend and try to gather info what's on. Annying. A few months ago the USB thing after resume that USB wasn't detected after reboot now this. Come on Linus don't fail me like that.
RiP, Jeff http://www.slayer.net/at/jeff-hanneman
Offline
The OPs problem is that the external output immediately wakes the system, not a crash-on-resume.
Also nvidia? => https://bbs.archlinux.org/viewtopic.php … 0#p2240550
Offline