hyprwm
Hyprlock has delayed focus after waking up from suspend to RAM
Regression?
No
Hyprlock Info and Version
Hyprlock version v0.7.0
Hyprlock config
general {
grace = 0
hide_cursor = true
no_fade_in = true
no_fade_out = true
ignore_empty_input = true
}
auth {
pam:enabled = true
}
background {
monitor = DP-1
color = rgba(25, 23, 36, 1) # Base color (dark background)
}
input-field {
monitor = DP-1
size = 20%, 5%
outline_thickness = 1
inner_color = rgba(25, 23, 36, 0.0) # Transparent inner color
placeholder_text = type here
outer_color = rgba(235, 188, 186, 1) # Rose color for outer border
check_color = rgba(156, 207, 216, 1) # Pine color for check
fail_color = rgba(235, 111, 146, 1) # Fail color (reddish)
fail_text = password incorrect
dots_rounding = 0
dots_text_format = *
dots_fade_time = 0
dots_center = false
font_color = rgb(224, 222, 244) # Text color (light)
fade_on_empty = false
rounding = 0
position = 0, -20
halign = center
valign = center
font_family = Iosevka Term
}
label {
monitor = DP-1
text = cmd[] uname --kernel-release
color = rgba(224, 222, 244, 1.0) # Text color (light)
font_size = 16
font_family = Iosevka Term
position = 0, -150
halign = center
valign = center
}
label {
monitor = DP-1
text = cmd[update:1000] date +"%H:%M"
color = rgba(156, 207, 216, 1.0) # Pine color for time
font_size = 55
font_family = Iosevka Term
position = 0, 250
halign = center
valign = center
}
label {
monitor = DP-1
text = $USER
color = rgba(235, 188, 186, 1.0) # Rose color for username
font_size = 25
font_family = Iosevka Term
position = 0, 80
halign = center
valign = center
}
shape {
monitor = DP-1
size = 40%, 35%
position = 0, 0
color = rgba(25, 23, 36, 0) # Transparent background
rounding = 0
border_size = 1
border_color = rgba(224, 222, 244, 0.8) # Light border color
}
Compositor Info and Version
System/Version info
Hyprland 0.47.0 built from branch main at commit 01f4074421059006b44b97cda00094a318e63d5f (hyprctl/layers: print pid for layershell clients (9468)).
Date: Wed Feb 26 16:03:06 2025
Tag: v0.47.0-103-g01f40744, commits: 5845
built against:
aquamarine 0.7.2
hyprlang 0.6.0
hyprutils 0.5.1
hyprcursor 0.1.11
hyprgraphics 0.1.2
no flags were set
System Information:
System name: Linux
Node name: ognjen-pc
Release: 6.13.5-arch1-1
Version: #1 SMP PREEMPT_DYNAMIC Thu, 27 Feb 2025 18:09:44 +0000
GPU information:
06:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU116 [GeForce GTX 1660 SUPER] [10de:21c4] (rev a1) (prog-if 00 [VGA controller])
NVRM version: NVIDIA UNIX x86_64 Kernel Module 570.124.04 Tue Feb 25 04:12:12 UTC 2025
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
plugins:
Description
When waking up from suspend, hyprlock doesn't immediatly take focus on the input field. Mouse is visible even though it's disabled in config. When I wait for 2 seconds, it automatically focuses, or when I move the mouse manually anywhere, it focuses. It's not a big deal and I don't know if this is a bug even, but it's kinda annoying.
How to reproduce
Suspend, wait for a bit wake up your PC.
Crash reports, logs, images, videos
No response
Hyprland bug, but yes I also encounter that from time to time. Will look into it at some point.
I think this is a big deal because it allows you to input any keystroke in the app that was focused just before you suspend to ram.
For example, having a terminal focused and suspending to ram allow anyone to input commands to your terminal in a few seconds window while hyper lock isn’t focused.
I think this is a big deal because it allows you to input any keystroke in the app that was focused just before you suspend to ram
Thanks for making that clear. Must be a weird code path in hyprland, cause focusing a window when locked is not allowed already.
I'm also having this delay but it does not input keystrokes to the focused apps. After sleeping, if I wait a few seconds everything works as expected but if I type right away, the first keystroke will only focus on the password input field but does not type it. Its annoying because I often get my password wrong because of this.
I tested sleeping with a open terminal and spamming keystrokes as the laptop woke up and nothing was registered on the previously focused terminal.
I am having a hard time reproducing this reliably. I know that it happen with suspend from time to time, but just suspending does not trigger it on my machine.
I think it could be related to how monitors behave during suspend, but unsure. If someone knows a more consistent way to reproduce it, let me know.
Also hyprlock+hyprland logs of the problem might help.
This happens on my laptop almost 100% of the time.
I noticed in the logs that this error keeps occurring:
---snip---
[ERR] Invalid key down event (stray release event?)
---snip---
which points to src/core/hyprlock.cpp:586 . It looks like some key events are being swallowed, so I made this patch:
@@ -584,7 +584,9 @@ void CHyprlock::onKey(uint32_t key, bool down) {
} else if (!down && std::ranges::find(m_vPressedKeys, key) == m_vPressedKeys.end()) {
Debug::log(ERR, "Invalid key down event (stray release event?)");
- return;
+ onKey(key, true);
+ onKey(key, false);
+ return;
}
which basically just simulates a keypress for the "swallowed" key. I need to test this some more, but as a hack it seems to fix the bug. Of course, a more proper solution is required, but hopefully this helps narrow down the root cause?
If others can check their logs and see if they are getting the same error, that would be helpful.
EDIT: On further testing, I think this is a hyprland issue and not hyprlock/hypridle. I'm seeing the same behaviour with swaylock+swayidle - the first key is being swallowed unless I move the mouse. Looking at the logs for hyprland, this happens whenever I suspend (even without any idle daemon):
uwsm_hyprland.desktop[73834]: The XKEYBOARD keymap compiler (xkbcomp) reports:
uwsm_hyprland.desktop[73834]: > Warning: Unsupported maximum keycode 708, clipping.
uwsm_hyprland.desktop[73834]: > X11 cannot support keycodes above 255.
uwsm_hyprland.desktop[73834]: > Warning: Could not resolve keysym XF86RefreshRateToggle
uwsm_hyprland.desktop[73834]: > Warning: Could not resolve keysym XF86Accessibility
uwsm_hyprland.desktop[73834]: > Warning: Could not resolve keysym XF86DoNotDisturb
uwsm_hyprland.desktop[73834]: Errors from xkbcomp are not fatal to the X server
and no other log messages are present.
Something I should have thought about earlier: Are you guys using focus follows mouse of manual focus??
I have follow_mouse = 1 (focus follows mouse) in my hyprland config.
PS: I'm not using hyprland atm so unfortunately I can't provide more detailed debug info for the time being.
Adding onto this thread, as I am also experiencing this issue.
Something I should have thought about earlier: Are you guys using focus follows mouse of manual focus??
My config has follow_mouse = 2 set.
If this is a Hyprland issue as others seem to suggest, do we have a tracking number for the issue within that repository? I haven't found an issue for this that is actively being monitored there.
Hyperland + hyprlock combo is barely usable for me. I'm now facing another issue 90% of the time after a suspend, where the screen shows as if it was unlocked but not responsive in the sense of mouse clicks or keyboard strokes doesn't do anything. I suspect hyprlock is active but somehow in the background, where it shows my desktop/running applications but I'm locked out of the session unable to unlock.
If anyone can give me a step-by-step on how to collect the logs of the relevant softwares that would be great. Happy to help. Though when that happens the only 'way out' is a force restart by long pressing the power button on my pc.
Also please advise if I should open a different issue for this behavior.
Thanks
@andrepatta This is your issue: https://github.com/hyprwm/hyprlock/issues/695
Sadly there are multiple issues with suspend currently. Some of them are nvidia only like yours probably. When I have more time I will make another attempt at fixing the nvidia issues.