Open brettalcox opened 6 months ago
Same issue here with an RTX 2070 Super. Sometimes it locks perfectly, sometimes it kinda "lags" for 2-3 seconds before the lockscreen appears. This can usually be sped up when e.g. moving the mouse.
I'm experiencing similar behaviour on an RTX 1080. Most animations freeze or are laggy, can be sped up by moving the mouse. This makes Hyprlock completely unusable, which is a shame since it is by far the nicest and most featureful option available for Wayland locking. An option to disable hardware acceleration would be nice, but I understand if this isn't feasible / is too much work.
I'd really love a workaround for NVIDIA. So far there's no other Wayland lockscreen that compares to Hyprland, but the constant lag and labels not updating makes it basically unusable :/
update periodically and check back. I can't make any fixes specifically for nvidia without someone from nvidia themselves pointing out the issues:
Next GPU gonna be red for sure
same here with rtx 3060, --verbose doesn't change it
Facing the same issue, hyprlock seems to run very slow (and gets slower the longer it is on). The animations feel like they're running on less than 10 frames per second.
Can confirm that moving the mouse while launching and typing the password results in smooth animations
I fixed the issue for my case by changing the polling rate from 5 seconds to 4ms (or 16ms) to poll on every monitor refresh rate. Created a pullrequest for a quick fix, though it might not be a good fix. https://github.com/hyprwm/hyprlock/pull/283
If you are on NixOS
{ pkgs, ... }:
{
programs.hyprlock = {
enable = true;
package = pkgs.hyprlock.overrideAttrs (old: {
version = "git";
src = pkgs.fetchFromGitHub {
owner = "hyprwm";
repo = "hyprlock";
rev = "2bce52f";
sha256 = "36qa6MOhCBd39YPC0FgapwGRHZXjstw8BQuKdFzwQ4k=";
};
patchPhase = ''
substituteInPlace src/core/hyprlock.cpp \
--replace "5000" "16"
'';
});
...
}
I fixed the issue for my case by changing the polling rate from 5 seconds to 4ms (or 16ms) to poll on every monitor refresh rate. Created a pullrequest for a quick fix, though it might not be a good fix. #283
Thanks for the workaround. Arch users can apply it by adding this to the PKGBUILD:
prepare() {
cd "${srcdir}/${_pkgname}"
sed -i -e "s/5000/16/g" src/core/hyprlock.cpp
}
Confirmed still a bug, running on Arch. I havn't tried the polling workaround yet. hyprland-git: 0.3.0.r30.gc5b8ad03-1 Nvidia Driver: 550.78 GPU: 1060 6GB
Still a bug for me too on arch, I tried to print logs but the only thing it tells me is Invalid key down event (stray release event?)
which is not that helpful
Hyprland: 0.41.2-3 Hyprlock: 0.4.1-1 Drivers: 555.58 GPU: 1070 Ti
Still an issue for me, but using the polling workaround fixed it.
Hyprland 0.41.2-3 Hyprlock-git 0.4.1.r4.g5e8f12c2-1 Nvidia-dkms Driver 555.58.02-1
Edit: specified hyprlock-git instead of hyprlock
Building at commit 19d7844f040c0290e23efc2e756ff75ce844248e
GPU: NVIDIA GeForce RTX 4090 WM: Hyprland Resolution: 2560x1440 (1x scale), 3840x2160 (1.5x scale)
Added the logs below of when this happens. The screen is still a bit transparent so i can still things occurring, and the last log before the freeze is the
[ERR] Invalid key down event (stray release event?)
. The screen will go slightly transparent, and freeze for 3-5 seconds before finally finishing the lock. Other times, it doesn't happen and its a nice smooth transition/fade out.Weirdly, I can't get this to actually reproduce when running
hyprlock --verbose
, only simply when runninghyprlock
, so not sure if this is a race condition.EDIT: here is my hyprlock.conf