You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have used swaylock successfully with sway for some time, to the degree that I don't actually know where to find logfiles, etc. to troubleshoot issues. My current testing setup is giving me issues however:
Environment:
Fedora Silverblue 37
swaylock 1.7.2 (layered on base system)
hyprland WM 0.23beta
Idle config located at ~/.config/swayidle/config; swayidle executed with swayidle -w (manually testing) or exec-once=swayidle -w (WM config). swayidle is launching correctly in each case and appears to be triggering swaylock based on (a) setting idle timer to a short time and waiting and (b) closing my laptop lid. What I can't tell is whether this is a quirk of Silverblue (swaylock having an issue with something on the immutable part of the system), hyprland (obviously under rapid and early development, and possibly missing or misfiring an event), or swaylock.
Expected Behavior:
Upon command (i.e., bound key such as SUPER+L), swayidle timer, or event (laptop lid closed), execute swaylock -f -c #000000, which locks the display and may perform other actions such as turning off the display. Appropriate action, such as tapping a key or opening the laptop lid displays the unlock screen, and typing the user password immediately unlocks the laptop.
Observed Behavior:
Swayidle and other events appear to correctly trigger swaylock, including related activities such as turning off the display. Waking (or returning to) the locked device appears to correctly show the lock screen. The lock screen appears to correctly receive inputs while typing (there's no stuttering or flickering indicating a possible input problem). However, the "Verifying" step sometimes times out, and it takes as many as 7-10 correct password entries (or, at least, verifying they are typed correctly by me) before the unlock will occur. Failed attempts do not display any error or warning at all. Sometime, though I haven't been able to repeat this consistently, it almost seems like the unlock and validation is happening but very, very slowly, so typing the password > validation > time passes > unlock successful.
The text was updated successfully, but these errors were encountered:
crawfordlong
changed the title
Swaylock requires multiple attempts with correct password to unlock
Swaylock requires (or appears to require) multiple attempts with correct password to unlock
Mar 21, 2023
I have used swaylock successfully with sway for some time, to the degree that I don't actually know where to find logfiles, etc. to troubleshoot issues. My current testing setup is giving me issues however:
Environment:
Fedora Silverblue 37
swaylock 1.7.2 (layered on base system)
hyprland WM 0.23beta
Idle config located at
~/.config/swayidle/config
; swayidle executed withswayidle -w
(manually testing) orexec-once=swayidle -w
(WM config). swayidle is launching correctly in each case and appears to be triggering swaylock based on (a) setting idle timer to a short time and waiting and (b) closing my laptop lid. What I can't tell is whether this is a quirk of Silverblue (swaylock having an issue with something on the immutable part of the system), hyprland (obviously under rapid and early development, and possibly missing or misfiring an event), or swaylock.Expected Behavior:
Upon command (i.e., bound key such as SUPER+L), swayidle timer, or event (laptop lid closed), execute
swaylock -f -c #000000
, which locks the display and may perform other actions such as turning off the display. Appropriate action, such as tapping a key or opening the laptop lid displays the unlock screen, and typing the user password immediately unlocks the laptop.Observed Behavior:
Swayidle and other events appear to correctly trigger swaylock, including related activities such as turning off the display. Waking (or returning to) the locked device appears to correctly show the lock screen. The lock screen appears to correctly receive inputs while typing (there's no stuttering or flickering indicating a possible input problem). However, the "Verifying" step sometimes times out, and it takes as many as 7-10 correct password entries (or, at least, verifying they are typed correctly by me) before the unlock will occur. Failed attempts do not display any error or warning at all. Sometime, though I haven't been able to repeat this consistently, it almost seems like the unlock and validation is happening but very, very slowly, so typing the password > validation > time passes > unlock successful.
The text was updated successfully, but these errors were encountered: