general {
after_sleep_cmd=hyprctl dispatch dpms on
before_sleep_cmd=loginctl lock-session
lock_cmd=hyprlock
}
listener {
on-timeout=loginctl lock-session
timeout=300
}
listener {
on-resume=hyprctl dispatch dpms on
on-timeout=hyprctl dispatch dpms off
timeout=330
}
listener {
on-timeout=systemctl suspend
timeout=600
}
Guys I feel like there’s something wrong or odd in this config, cuz, I don’t know whats responsible for this but, it looks like things aren’t working well together, I said it looks like cuz I never caugth an actual error. So what happens is that after I leave my laptop idle, the hypridle starts doing its thing and most of the times it works, my laptop is suspended, hyprlock works etc, but sometimes, after I press any button on my keyboard to wake my laptop, I can see that my laptop is up, but all I can see is black screen, and then I have to hard shutdown the laptop, so somethings is not adding up here.
This problem happens with my display connected to an NVIDIA card. I just made a hotkey that edits the Monitors entry for that display which triggers Hyprland to re-read the configuration and activate the monitor.
You should still be able to get to a virtual terminal (Ctrl + Alt + [F1-F6] so you can do this manually.
I don’t know a thing about hyprland specifically, but first enable persistent journal so you will be able to look what exactly happened before black screen.
After enabling look at the end of the previous boot, probably it has nothing to do with hyprland.
Note: you’re reposting this oddly and it’s showing as a trail of links back here.
Couple things:
- Post system info: distro, kernel version, GPU, display connection…etc
- Don’t just hard shutdown, you need to see what
dmesgsays. Try ssh’ing into the machine when the display doesn’t come up. - Trigger something to reset your display mode. Switch to a new TTY, unplug/replug display…etc.
- Do you know what sleep modes your hardware supports?
dmesg gets written to journal, there is no point to ssh into machine.
Not always since it’s read directly from the ring buffer, and it matters because this is a point-in-time issue. If the machine is still responsive, and dmesg can display state information about what just happened, it’s easy to see if the machine is stuck recovering from standby, having issues with the display, outputting driver errors…etc.
That’s the like super convoluted way to do it, dmesg buffer is extremely short, and he will see everything relevant in the log. It’s 90% video driver issue anyeay.
Dmesg is as long as the ring keeps it. Mine, for instance, is set to roll from boot to shutdown. Reading it from journal after the fact is convoluted when you’re dealing with state.
