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.

  • FauxLiving@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    3 days ago

    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.

  • nesc@lemmy.cafe
    link
    fedilink
    English
    arrow-up
    1
    ·
    3 days ago

    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.

  • just_another_person@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    3 days ago

    Note: you’re reposting this oddly and it’s showing as a trail of links back here.

    Couple things:

    1. Post system info: distro, kernel version, GPU, display connection…etc
    2. Don’t just hard shutdown, you need to see what dmesg says. Try ssh’ing into the machine when the display doesn’t come up.
    3. Trigger something to reset your display mode. Switch to a new TTY, unplug/replug display…etc.
    4. Do you know what sleep modes your hardware supports?
    • nesc@lemmy.cafe
      link
      fedilink
      English
      arrow-up
      1
      arrow-down
      1
      ·
      3 days ago

      dmesg gets written to journal, there is no point to ssh into machine.

      • just_another_person@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        arrow-down
        1
        ·
        3 days ago

        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.

        • nesc@lemmy.cafe
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          1
          ·
          3 days ago

          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.

          • just_another_person@lemmy.world
            link
            fedilink
            English
            arrow-up
            1
            ·
            3 days ago

            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.