hyprwm / hyprlock

Hyprland's GPU-accelerated screen locking utility
BSD 3-Clause "New" or "Revised" License
717 stars 53 forks source link

sometimes successfully unlocks, but blocks all input and doesn't exit #459

Open rohrsben opened 1 month ago

rohrsben commented 1 month ago

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 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

bug.txt no_bug.txt

PaideiaDilemma commented 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?

wosym commented 4 weeks ago

Might be related to this? https://github.com/hyprwm/hyprlock/issues/419

rohrsben commented 4 weeks ago

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?

PaideiaDilemma commented 4 weeks ago

Can someone get some logs from hyprland (+your exact hyprland version) when that happens?

suderman commented 4 weeks ago

I have been experiencing this too for a long while now.

rohrsben commented 4 weeks ago

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.

log.txt

Edit: Hyprland, built from branch at commit 77cf651825c2afac69e3a827ff910a62c73e1218 (). Date: 2024-08-12 Tag: , commits: 77cf651825c2afac69e3a827ff910a62c73e1218

flags: (if any)

wosym commented 4 weeks ago

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.

rohrsben commented 3 weeks ago

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.

PaideiaDilemma commented 3 weeks ago

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?

rohrsben commented 3 weeks ago

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.

wosym commented 2 weeks ago

@PaideiaDilemma I tried this and was able to reproduce it.

PaideiaDilemma commented 2 weeks ago

@wosym also with the general:no_fade_out option set to true?

wosym commented 2 weeks ago

@PaideiaDilemma Yes, that was the thing I tried in that comment. It triggered the issue after just 3 locks.

Alvin21Bon commented 2 weeks ago

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.

Alvin21Bon commented 2 weeks ago

I've found how to 100% reproduce this issue on my system, need to see if this works on other systems too:

  1. Enable hyprlock in any way (bind, hyprlock, systemctl lock-session)
  2. Enter password while sporadically moving the mouse
  3. 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

PaideiaDilemma commented 2 weeks ago

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.

wosym commented 2 weeks ago

I am indeed on Nvidia... :cry:

It's not the first time Nvidia picks a fight with hyprlock in my case...

Alvin21Bon commented 2 weeks ago

Also on nvidia with the proprietary drivers. classic nvidia moment