Can't type after resuming from suspend

[lucasreis1]

I'm using hypridle to trigger hyprlock before suspending. After resuming, I can move my mouse and the clock updates, which signals that hypridle is working fine, but keyboard input won't work in the password box.

hypridle.conf:

general {
  before_sleep_cmd = WAYLAND_DEBUG=1 ~/.config/hypr/scripts/lock.sh &> /tmp/hyprlock_out.txt
  after_sleep_cmd = ~/.config/hypr/scripts/wp_init.sh -r
}

listener {
  timeout = 600
  on-timeout = ~/.config/hypr/scripts/lock.sh --dimfirst
}

listener {
  timeout = 720
  on-timeout = hyprctl dispatch dpms off
}

lock.sh:

#/bin/bash

WALLPAPER_DIR=~/Pictures/wallpapers/blurred
CURRENT_WALL=$(wpg -c)


EXTENSION="${CURRENT_WALL##*.}"
# for gifs, replace fframe with the gif.
# also, remember they are stored in the subfolder "animated"
if [[ "$EXTENSION" =~ fframe.*$ ]]; then
  CURRENT_WALL=${CURRENT_WALL%.*}.png
fi

IMG="$WALLPAPER_DIR/$CURRENT_WALL"

if [ ! -f $IMG ];
then
  IMG=$(ls $WALLPAPER_DIR/* | shuf | head -n 1)
fi
cp $IMG /tmp/hyprlock.png
#swaylock -f -i $IMG
if [ "$1" == "--dimfirst" ]
then
  chayang -d 10 && hyprlock 
else
  hyprlock
fi

hyprland.log:

[LOG] Instance Signature: 29cdd7de1f8d99462915540569fbe54f10f609f4_1709181372
[LOG] Hyprland PID: 396621
[LOG] ===== SYSTEM INFO: =====
[LOG] System name: Linux
[LOG] Node name: lucas
[LOG] Release: 6.7.6-arch1-1
[LOG] Version: #1 SMP PREEMPT_DYNAMIC Fri, 23 Feb 2024 16:31:48 +0000


[LOG] GPU information:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104 [GeForce RTX 3070 Lite Hash Rate] [10de:2488] (rev a1) (prog-if 00 [VGA controller])


[WARN] Warning: you're using an NVIDIA GPU. Make sure you follow the instructions on the wiki if anything is amiss.

[LOG] os-release:
NAME="Arch Linux"
PRETTY_NAME="Arch Linux"
ID=arch
BUILD_ID=rolling
ANSI_COLOR="38;2;23;147;209"
HOME_URL="https://archlinux.org/"
DOCUMENTATION_URL="https://wiki.archlinux.org/"
SUPPORT_URL="https://bbs.archlinux.org/"
BUG_REPORT_URL="https://gitlab.archlinux.org/groups/archlinux/-/issues"
PRIVACY_POLICY_URL="https://terms.archlinux.org/docs/privacy-policy/"
LOGO=archlinux-logo

[LOG] ========================



[INFO] If you are crashing, or encounter any bugs, please consult https://wiki.hyprland.org/Crashes-and-Bugs/


[LOG] 
Current splash: Take on me, take me on...


[LOG] Creating the HookSystem!
[LOG] Creating the KeybindManager!
[LOG] [hookSystem] New hook event registered: configReloaded
[LOG] Creating the AnimationManager!
[LOG] Created a bezier curve, baked 255 points, mem usage: 4.08kB, time to bake: 25.07µs. Estimated average calc time: 0.14µs.
[LOG] Creating the ConfigManager!
[LOG] NOTE: further logs to stdout / logfile are disabled by default. Use debug:disable_logs and debug:enable_stdout_logs to override this.
[LOG] Created a bezier curve, baked 255 points, mem usage: 4.08kB, time to bake: 10.90µs. Estimated average calc time: 0.14µs.
[LOG] Using config: /home/lucas/.config/hypr/hyprland.conf

hyprlock_out.txt

[LeGmask]

I've the same issue, after suspend I cannot type my password anymore...

[ArvineKwok]

same here

[MathisP75]

Same issue here

[harshkhandeparkar]

I would like to add that for me, the textbox types 3 dots for each character typed after waking from suspend.

[FearlessSpiff]

I would like to add that for me, the textbox types 3 dots for each character typed after waking from suspend.

this is fixed. build from source...

[dtk9289]

bump

[lucasreis1]

I'm sorry but why is this closed as completed? I'm still experiencing the issue on latest git for hyprland, hypridle and hyprlock.

[vaxerski]

I assumed "this is fixed" and 3 likes meant this is fixed. Are you sure you're on latest git? no duplicate binaries?

[sefodopo]

I can also confirm that I had this issue on the latest git this morning when I woke up to wake up my computer from sleep. It wouldn't take in any input, also if I remember correctly, the mouse cursor was also showing which isn't supposed to be showing.

However, after this issue was closed, I looked around at other issues and ran across #76. In that issue it was mentioned that the crashing only occurs when running systemctl suspend from a terminal and not when ran by hypridle. So far today, after making that change (and updating to the latest commit this morning b4a1c8c, I haven't had this issue. But I also haven't went to sleep overnight again.
I will update hyprlock again before bed tonight to the latest git and test this again.

I think the "this is fixed" was referring to a side tangent of "the textbox types 3 dots for each character typed after waking from suspend" which isn't what it looks like the first post was talking about.

[lucasreis1]

I assumed "this is fixed" and 3 likes meant this is fixed. Are you sure you're on latest git? no duplicate binaries?

I'm pretty sure he was replying to the person who pointed to another adjacent issue (typing three dots for each character). The original problem from suspending is still present here.

[lucasreis1]

In that issue it was mentioned that the crashing only occurs when running systemctl suspend from a terminal and not when ran by hypridle

Can you clarify what running "suspending by hypridle" means? The only way I was aware of running suspend without writing to system files is directly from systemd.

[sefodopo]

So if I run systemctl suspend from kitty, then go to sleep while using hypridle with lock_cmd = pidof hyprlock || hyprlock and before_sleep_cmd = loginctl lock-session, Hyprlock won't let me input any text in the morning when I wake up and wake my computer.

On the other hand if I add a listener in hypridle to on-timeout = systemctl suspend and wait for my computer to go to sleep (instead of manually running systemctl suspend, I was unable to recreate this bug. Hyprlock worked correctly upon waking up. Also, hyprlock seemed to work okay when I did hyprctl keyword exec systemctl suspend. Granted, I haven't tested any of these other methods overnight. It may take time to cause the issue, or the latest commits late last night or early this morning fixed this bug.

I also did a quick test earlier today running systemctl suspend from kitty, and then immediately waking the computer up within a minute, and hyprlock worked correctly. So either the latest commits fixed it, or it takes all night for an issue to appear.

[FearlessSpiff]

I assumed "this is fixed" and 3 likes meant this is fixed. Are you sure you're on latest git? no duplicate binaries?

I'm pretty sure he was replying to the person who pointed to another adjacent issue (typing three dots for each character). The original problem from suspending is still present here.

Yes. The three dots is fixed. The other problem I don't know. Never a good idea to add other issues in an issue.

[hakan-demirli]

I can replicate what @sefodopo described, on NixOS on e9a57f0 commit.

[PaideiaDilemma]

So I suspect, that hypridle is running multiple times for you guys. That way I was able to reproduce it (happened to myself by accident, because in nix you don't have to exec it since hypridle starts when services.hypridle.enable = true).

That would cause hyprlock to be launched twice and one instance would receive the finished event which would lock it up.

[hakan-demirli]

So, a simple solution would be running pidoff hyprlock inside hyprlock when it is first launched to detect if anyother hyprlock instance is running and then exit if it is?

PS: I do not use the home-manager module/service. I just add pkgs.hyprlock+ override src and lock my screen using a lockscreen key.

[PaideiaDilemma]

You could try this patch and see if you are still able to repro.
patch.txt

[lucasreis1]

I've tried the patch and the issue persists. But oddly enough running ps -aux --forest on another tty shows that indeed, the before-sleep command is being called more than one, even if hyprlock is called only once:

lucas     914040  0.0  0.0   7520  3712 tty2     S+   13:55   0:00 /bin/sh -c WAYLAND_DEBUG=1 ~/.config/hypr/scripts/lock.sh &> /tmp/hyprlock_out.txt
lucas     914041  0.0  0.0   7520  2304 tty2     S+   13:55   0:00  \_ /bin/sh -c WAYLAND_DEBUG=1 ~/.config/hypr/scripts/lock.sh &> /tmp/hyprlock_out.txt
lucas     914065  0.4  0.4 905528 160056 tty2    Sl+  13:55   0:00      \_ /tmp/tmp.xMscfB99bP/hyprlock/build/hyprlock

[PaideiaDilemma]

If your before_sleep script gets called twice shouldn't hyprlock get called twice as well?

[PaideiaDilemma]

There is probably also something else going on. If you start it with pidof hyprlock || hyprlock it should be fine. I just got a bug where hyprlock stops accepting input after suspend, but after a few seconds it started to work again.

[lucasreis1]

Upon further investigation, spawning an identical child seems to be a perk of the way hypridle runs execl and pipe redirection when running under shell scripts (i.e. this only happens when before_sleep_cmd is a shell script that redirects its output).

if I do

before_sleep_cmd = hyprlock

I don't see two processes with the same input when running ps aux --forest, but the problem of being unable to type after suspend on hyprlock persists.

I just got a bug where hyprlock stops accepting input after suspend, but after a few seconds it started to work again.

I can't replicate this. I can wait as long as I want, I cannot type if I resume from suspend.
If I could take a wild guess, I'd say nvidia is to blame here.

[Cody-W-Tucker]

If I could take a wild guess, I'd say nvidia is to blame here.

Non nvidia user here with the same problem. But other NixOs users have a similar problem with swaylock and swayidle. swaywm/swaylock#344

So I suspect, that hypridle is running multiple times for you guys. That way I was able to reproduce it (happened to myself by accident, because in nix you don't have to exec it since hypridle starts when services.hypridle.enable = true).

I searched NixOs options unstable and couldn't find it. Where is that service?

[PaideiaDilemma]

Where is that service?

The option is in the hm-module contained in this repo :)

As described in #190 I ran into this issue.
Not sure if that fixes it but we will see.

But it is good to check that there aren't multiple hyprlock instances running. Can lead to similar symptoms.

[Cody-W-Tucker]

Where is that service?

The option is in the hm-module contained in this repo :)

That's really cool, how can I use it? Is it with a flake?

[fufexan]

Where is that service?

The option is in the hm-module contained in this repo :)

That's really cool, how can I use it? Is it with a flake?

Yup. You add inputs.hyprlock.url = "github:hyprwm/hyprlock"; to your flake, then add inputs.hyprlock.homeManagerModules.default to your HM's imports list.

[PaideiaDilemma]

happened again to me, but I don't see anything wrong in hyprlock when it happens.

[MathisP75]

I am still facing this issue on the latest git

[vaxerski]

patch.txt
try this

[MathisP75]

error: src/managers/input/InputManager.cpp: No such file or directory
Where even is InputManager.cpp?

[vaxerski]

thats hyprland

[MathisP75]

I applied the patch to the latest git of Hyprland and the issue still persists.

[RoccoRakete]

I can confirm, I'm experiencing this issue on nixOS too.

[lucasreis1]

I applied the patch to the latest git of Hyprland and the issue still persists.

Same here. Applied to commit 356414639fc06ace7045236ec41d673342981057, no changes.

[PaideiaDilemma]

And are you guys sure that hyprlock has not been launched multiple times?

[RoccoRakete]

And are you guys sure that hyprlock has not been launched multiple times?

Pretty sure, since it happens only sometimes. Manly when the laptop is on sleep, locked, and I unplug the monitor, before I wake the laptop up.

[PaideiaDilemma]

Ok yeah that sounds like hyprlock loosing focus. Have not experienced that since hyprwm/Hyprland#5117

[lucasreis1]

Here's some logs from Hyprland (latest git) after I replicated the issue again:

log.txt

Oddly enough it seems like hyprlock is spawning after resume even if I specify as the before_sleep_cmd

[SebastianStork]

I also have this issue. Doing systemctl suspend either from the terminal or a keybind results in not being able to log back in afterwards. Suspend through hypridle has no issues.

I am 100% sure that the issue is from hyprlock losing focus. When I focus kitty before suspending and then wake up, I am able to run commands in the still open terminal (I can see them in the bash history later).

I am on the latest git. I use NixOS and nvidia.

On my amd laptop I have none of these issues.

[Omrigan]

Also have this. Launching hyprlock with pidof hyprlock || hyprlock. hypridle config is:

general {
    before_sleep_cmd = lock.sh
    ignore_dbus_inhibit = false             # whether to ignore dbus-sent idle-inhibit requests (used by e.g. firefox or steam)
}

listener {
    timeout = 300                            # in seconds
    on-timeout = idlelock.sh
}

When hyprlock is triggered by timeout or launched directly, this doesn't happen.

Any suggestions what to do or workarounds?

[Omrigan]

Actually, just checked:

• hypridle + swaylock: same issue
• swayidle + swaylock: no issue
• swayidle + hyprlock: no issue

So I suspect it is a hypridle thing 🙃

[endeavour]

Also seeing this issue although not consistently. Perhaps it's a race condition?

[djvs]

I have the issue with swayidle + hyprlock, on a non-systemd setup (elogind). Quickly reproducible by power cycling my monitor in a lock state. Also, power cycling the monitor in an unlocked state changes the workspace, which I can't help but feel is related.

Also breaks with waylock, and IIRC swaylock.

[BRS5672023]

I find it rather peculiar that there's no issue unlocking hyprlock if I lock the session manually, say, by set bind=$mainMod,U,exec,hyprlock in hyprland.conf. But it is quite frequent that hyprlock does not read my password input if hyprlock is invoked by hypridle. For reference, the following is my hypridle.conf

general {
	ignore_dbus_inhibit = false
	lock_cmd = pidof hyprlock || hyprlock
	before_sleep_cmd = loginctl lock-session
	after_sleep_cmd = hyprctl dispatch dpms on
}

listener {
	timeout = 600
	on-timeout = loginctl lock-session
}

listener {
	timeout = 630
	on-timeout = hyprctl dispatch dpms off
	on-resume = hyprctl dispatch dpms on
}

listener {
	timeout = 30
	on-timeout = pidof hyprlock && hyprctl dispatch dpms off
	on-resume = hyprctl dispatch dpms on
}

And this issue is not present if I enter the password right after the locking timeout, but only after certain amount of time passed from this timeout (such behavior presents both on my laptop and desktop pc), this very same issue also appears when I use swaylock instead...

[MoltenB]

I am having the same issue. Works fine after hibernation, not using suspend.

[olealgoritme]

Same issue. Ubuntu 24.04. Works fine after hibernate, not when using suspend.

[SebastianStork]

I did some more experimentation. When I have

general {
  lock_cmd = pidof hyprlock || hyprlock
  before_sleep_cmd = loginctl lock-session
  after_sleep_cmd = hyprctl dispatch dpms on
}

and do a systemctl suspend, I get an unresponsive black screen after wake. When I do a loginctl lock-session && systemctl suspend without the before_sleep_cmd I get the same result. loginctl lock-session && sleep 1 && systemctl suspend works without a problem. Sadly this can't be transferred to before_sleep_cmd = loginctl lock-session && sleep 1 as hypridle doesn't wait for the command to finish.

It seems to me like my issue is caused by not giving hyprlock time to launch before suspending. Any delay between the two fixes the issue.

But my current issue is different than the one I reported back in april. Back then I just couldn't focus hyprlock to log back in after a suspend, everything else was fine. Now I get a black screen and my pc becomes completely unresponsive. The caps lock light doesn't work but audio that played before the suspend keeps playing.

[PaideiaDilemma]

@SebastianStork can you try this patch for hyprIDLE?

patch.txt

[SebastianStork]

@SebastianStork can you try this patch for hyprIDLE?

patch.txt

Is there an easy way to apply the patch on NixOS?

[PaideiaDilemma]

1. clone hypridle
2. apply the patch with wget https://github.com/user-attachments/files/16311838/patch.txt && git apply patch.txt
3. nix run .

Maybe kill your running instance of hypridle first as well.

[SebastianStork]

I get the same result result with the patch: a black screen after wake, all keybinds are unresponsive, caps lock light is unresponsive, audio keeps playing

[PaideiaDilemma]

Ok and this?
patch2.txt

Please also report if you see hyprlock start up, before the system suspends and monitors go dark.
Also check if using before_sleep_cmd = pidof hyprlock || hyprlock instead of loginctl lock-session works.

[SebastianStork]

before_sleep_cmd = loginctl lock-session doesn't work. It goes straight to black and I experience the same issues I described above.
With before_sleep_cmd = pidof hyprlock || hyprlock it works. The lock screen shows up and after ~4 seconds the pc goes to sleep.

[SebastianStork]

Strangely, if I first lock the screen using loginctl lock-session and then suspend using a keybind, I end up with two lock screens, one from the initial screen lock and another from the suspend action. However, this issue doesn't occur if I lock the screen with pidof hyprlock || hyprlock before suspending.

There seems to be an issue with lock_cmd = pidof hyprlock || hyprlock.

[PaideiaDilemma]

Thanks for testing @SebastianStork.

I am a bit surprised that I cannot reproduce that. But it seem like going through dbus via loginctl lock-session causes hyprlock to be launched too late or smth. I think for now you have a workaround by using before_sleep_cmd = pidof hyprlock || hyprlock for now.

Strangely, if I first lock the screen using loginctl lock-session and then suspend using a keybind, I end up with two lock screens, one from the initial screen lock and another from the suspend action.

Obviously, since first lock is triggered by loginctl lock-session and hypridles lock_cmd and the second one from the before_sleep_cmd.