hyprwm
sometimes successfully unlocks, but blocks all input and doesn't exit
Regression?
No
Hyprlock Info and Version
Hyprlock version 0.4.1 (via nix flake)
Hyprlock config
background {
monitor =
color = rgba(105, 109, 162, 1.0)
}
Compositor Info and Version
System/Version info
Hyprland, built from branch at commit 77cf651825c2afac69e3a827ff910a62c73e1218 ().
Date: 2024-08-12
Tag: , commits: 77cf651825c2afac69e3a827ff910a62c73e1218
flags: (if any)
System Information:
System name: Linux
Node name: authenticationerror
Release: 6.10.1-zen1
Version: #1-NixOS ZEN SMP PREEMPT_DYNAMIC Tue Jan 1 00:00:00 UTC 1980
GPU information:
02:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU102 [GeForce RTX 2080 Ti Rev. A] [10de:1e07] (rev a1) (prog-if 00 [VGA controller])
NVRM version: NVIDIA UNIX Open Kernel Module for x86_64 555.58.02 Release Build (nixbld@) Mon Aug 5 16:39:34 UTC 2024
os-release: ANSI_COLOR="1;34"
BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
BUILD_ID="24.11.20240809.5e0ca22"
DOCUMENTATION_URL="https://nixos.org/learn.html"
HOME_URL="https://nixos.org/"
ID=nixos
IMAGE_ID=""
IMAGE_VERSION=""
LOGO="nix-snowflake"
NAME=NixOS
PRETTY_NAME="NixOS 24.11 (Vicuna)"
SUPPORT_URL="https://nixos.org/community.html"
VERSION="24.11 (Vicuna)"
VERSION_CODENAME=vicuna
VERSION_ID="24.11"
plugins:
Description
Sometimes (10-20% of the time?) after inputting my password hyprlock's color background will disappear, but seemingly all input will be blocked (can't type in terminal, firefox's gui looks like the app isn't focused, etc). For whatever reason switching to a second tty fixes this. No login required, just switch there and back and hyprlock will finish the authentication and exit.
Testing this out by running hyprlock from a terminal shows that the final log (at least until switching to another tty) is [LOG] auth: authenticated for hyprlock. The only thing amiss in the logs afterward are some extra graphical outputs occurring directly after that line, only when the bug happens. In my nixos config i have the line security.pam.services.hyprlock = {}; to provide a pam.d/hyprlock file, but this doesn't matter; the issue happens even if hyprlock has to fallback to su authentication.
How to reproduce
In any way run hyprlock. Anecdotally it feels like the issue happens more when its started by hypridle, but... who knows.
Crash reports, logs, images, videos
That is odd.
The only thing amiss in the logs afterward are some extra graphical outputs occurring directly after that line, only when the bug happens
That kinda stands out. Why would we get [LOG] output 46 done at that point?
Anybody else running into this issue?
No idea if they're related, but for me the screen doesn't actually freeze, I just can't interact with applications. It's more like the graphical part of hyprlock disappears but the blocking behaviour remains. Just tested it by having python count in a terminal for me (let it run for about 5 minutes in case time matters), and I can still see the terminal update, I just can't interact with it.
Do you get the graphical [LOG] lines that I do?
Can someone get some logs from hyprland (+your exact hyprland version) when that happens?
Here's a log for you @PaideiaDilemma. Process: boot, start hyprland and a kitty window, then immediately begin running hyprlock until the bug happens. Got lucky and had it happen on just the second try.
Kitty set its title to hyprlock at lines 1476 (the no bug one) and 1504 (the bug one) as points of interest. I ran hyprlock again after switching ttys to get some additional data, but for the first time ever even though I could interact with waybar, kitty itself froze after switching back. I don't think this is related.
Edit: Hyprland, built from branch at commit 77cf651825c2afac69e3a827ff910a62c73e1218 (). Date: 2024-08-12 Tag: , commits: 77cf651825c2afac69e3a827ff910a62c73e1218
flags: (if any)
No idea if they're related, but for me the screen doesn't actually freeze, I just can't interact with applications. It's more like the graphical part of hyprlock disappears but the blocking behaviour remains. Just tested it by having python count in a terminal for me (let it run for about 5 minutes in case time matters), and I can still see the terminal update, I just can't interact with it.
I've also experienced that a couple of times. Usually it's a full freeze, but indeed, twice I've also seen that applications are still running, but I can't interact with them.
I was idly contemplating this, and realized that the output 46 done and related lines might simply be red herrings. They happen because I switch ttys, and upon switching back all the graphical stuff needs to be redone.
I tested this by switching ttys a few times before entering my password, and indeed you get copies of the graphical [LOG] lines for every switch. Notably these "early" tty switches had no effect on whether hyprlock froze after inputting the password.
So I suppose the question really is just why switching ttys causes hyprlock to finish up its exit process.
Yeah i think you are right about that @rohrsben.
Can you try to disable fadeout via general:no_fade_out and check if you can still reproduce it?
Initially this does seem to fix the issue! I'm gonna rig something up to automatically test this a bunch of times since random chance bugs are annoying, but tentatively this works.
@PaideiaDilemma Yes, that was the thing I tried in that comment. It triggered the issue after just 3 locks.
I am experiencing this same issue and it can fix itself if I unplug my keyboard. Running hyprlock in the terminal shows the same result where it hangs on [LOG] auth: authenticated for hyprlock, but once I unplug my keyboard the system resumes.
I've found how to 100% reproduce this issue on my system, need to see if this works on other systems too:
- Enable hyprlock in any way (bind,
hyprlock,systemctl lock-session) - Enter password while sporadically moving the mouse
- system now hangs until keyboard is unplugged
This works regardless of if the cursor is hidden or not
Also note: this method does not work if no_fade_out is set to true
So here is what I think happens:
The session is actually still locked. The workspace shows, because Hyprland allows rendering the workspace when a lock screen client and surface is present for faster screencopy and fade out.
Somehow Hyprland never receives the unlock request. also hyprlock does not destroy it's surfaces (otherwise it would be a red screen). My current guess is that the wayland session hangs and all of you are on nvidia? I can sadly not reproduce it.
I am indeed on Nvidia... :cry:
It's not the first time Nvidia picks a fight with hyprlock in my case...
I am still experiencing this issue (nixos + nvidia), it gets fixed by unplugging my keyboard. Update: on hyprland 0.45.0 and hyprlock 0.5.0 it doesn't get fixed buy unplugging the keyboard
I've seen this both on Nvidia and Intel. It's rare that I experience this on my Intel systems, but it's just about every time I lock the screen on my Nvidia system.
I am also rarely getting this issue (nvidia gpu with proprietary drivers) and i can fix it by switching to another tty and back
Thanks for reporting guys. I think this is an actual problem with fade out that i am going to fix soon!
As of https://github.com/hyprwm/hyprlock/pull/582, fade-out was re-implemented. Let me know if anyone is still having this issue!
Just saw this and ran some tests... which is how I discovered my no_fade_out/in settings haven't been working for days now. Seeing as I had no idea, I'm gonna mark this as closed. Thanks for the fix :)