-
-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[nvidia] Intermittently freezing for few seconds after lock #128
Comments
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. #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"
'';
});
...
} |
Thanks for the workaround. 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. |
Still a bug for me too on arch, I tried to print logs but the only thing it tells me is Hyprland: 0.41.2-3 |
Still an issue for me, but using the polling workaround fixed it. Hyprland 0.41.2-3 Edit: specified hyprlock-git instead of hyprlock |
Building at commit 19d7844
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
The text was updated successfully, but these errors were encountered: