Open rohrsben opened 1 month ago
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?
Might be related to this? https://github.com/hyprwm/hyprlock/issues/419
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?
I have been experiencing this too for a long while now.
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 I tried this and was able to reproduce it.
@wosym also with the general:no_fade_out
option set to true?
@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:
hyprlock
, systemctl lock-session
)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...
Also on nvidia with the proprietary drivers. classic nvidia moment
Regression?
No
Hyprlock Info and Version
Hyprlock version 0.4.1 (via nix flake)
Hyprlock config
```sh background { monitor = color = rgba(105, 109, 162, 1.0) } ```Compositor Info and Version
System/Version info
```sh 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 linesecurity.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
bug.txt no_bug.txt