[bug] i3lock doesn't seem to register the first couple of keypresses of password

[ShadowStar019]

I'm submitting a…

[x] Bug
[ ] Feature Request
[ ] Other (Please describe in detail)

Current Behavior

Sometimes, i3lock seems to skip the first couple of keypresses of my password after I close my laptop lid, wait an extended period of time (10 - 40 min), and then open my laptop lid. The green circle animation doesn't appear until after I make about 1-3 keypresses, and password verification fails.

Expected Behavior

Keypresses would register immediately when I start typing, the green circle animation would appear at the first keypress, and password verification would succeed if I type my password correctly.

Reproduction Instructions

1. Run i3lock from the terminal
2. Close laptop lid
3. Wait 10 - 40 min
4. Open laptop lid
5. Try typing in password

Environment

Output of i3lock --version:

i3lock: version 2.14.1 © 2010 Michael Stapelberg

i3 config: None; I just type i3lock in the terminal and hit enter every time I want to lock my laptop
System: Arch Linux x86_64

[orestisfl]

Are you sure your laptop registers the key presses? For example, try to temporarily disable locking on suspend and have a terminal open. Close the lid and then open it after a while and immediately start typing. Does everything get registered?

…

On Fri, 19 Apr 2024, 16:03 ShadowStar019, ***@***.***> wrote: I'm submitting a… [x] Bug [ ] Feature Request [ ] Other (Please describe in detail) Current Behavior Sometimes, i3lock seems to skip the first couple of keypresses of my password after I close my laptop lid, wait an extended period of time (10 - 40 min), and then open my laptop lid. The green circle animation doesn't appear until after I make about 1-3 keypresses, and password verification fails. Expected Behavior Keypresses would register immediately when I start typing, the green circle animation would appear at the first keypress, and password verification would succeed if I type my password correctly. Reproduction Instructions 1. Run i3lock from the terminal 2. Close laptop lid 3. Wait 10 - 40 min 4. Open laptop lid 5. Try typing in password Environment Output of i3lock --version: i3lock: version 2.14.1 © 2010 Michael Stapelberg i3 config: None; I just type i3lock in the terminal and hit enter every time I want to lock my laptop System: Arch Linux x86_64 — Reply to this email directly, view it on GitHub <#354>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMCZPRQL6TPCUUBABZOVALY6EP4TAVCNFSM6AAAAABGPIAKYKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI2TGMJQGY4TONQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[ShadowStar019]

Everything gets registered in the terminal after closing, waiting and opening the laptop lid.
One thing I noticed when i3lock misses keypresses is that on the first registered keypress, all of the arcs from the missed keypresses appear in rapid succession before the arc from the first registered keypress. For example, when the first registered keypress is the third keypress made, three green arcs appear in rapid succession around the center circle.

[stapelberg]

Can you try the following:

1. Start i3lock from terminal as usual.
2. Enter a few key presses to make sure i3lock has fully started and is processing key presses
3. Then close the lid, re-open, check if key presses are lost / delayed

Once i3lock enters its event loop, it’s up to X11 to deliver keypress events. If there are delays, that usually means something else is happening on the X11 level (e.g. monitor re-detection / configuration), but even so, keypresses should never get lost.

Also run i3lock --debug (but be sure to redact your password from the output), perhaps that gives us a hint as to what might be happening.

[stapelberg]

Oh, and also, can you try if slock (https://tools.suckless.org/slock/) or xsecurelock (https://github.com/google/xsecurelock) exhibit the same problem on your machine?

[ShadowStar019]

For some reason, I couldn't reproduce the issue since the last comment. I regularly update and install pacman packages, so it could have been a buggy package related to the keyboard input or laptop lid.

Now, no keypresses are lost / delayed and everything works as expected.
I tested slock on my machine and it works perfectly fine.

[orestisfl]

Thank you for letting us know. I'll close this until something newer comes up.