Hi Michael Thanks to the fix for #602101, I could narrow the problem. This is due to numbers in password (again). Indeed the problem I reported does not more exist if I use the numpad (provided i3lock is built with the fix for #602101). Therefore i3lock actually remains responsive but the problem is still here.
I must mention that I use a french keyboard layout with: XKBMODEL="pc105" XKBLAYOUT="fr" XKBVARIANT="oss" XKBOPTIONS="lv3:ralt_switch,compose:rwin" If I do not use the numpad, I need to use the shift key for numbers (using keys from first row). And this does not work, unless a key (any one) has been hit before i3lock is started. I also noticed that if I use the capslock key instead of the shift key for numbers (only for numbers because capital and minuscule letters are also inverted), I can authenticate. BTW, the simplest test case I found is: startx -- :3 with .xinitrc containing: sleep 5 i3lock -n The sleep command allows testing the impact of a key being hit before i3lock is started. To sum up (tested with latest version from git tree): - no key hit before i3lock starts; numbers with numpad -> ok - no key hit before i3lock starts; numbers with capslock and first row-> ok - no key hit before i3lock starts; numbers with shift key and first row-> fail - random key hit before i3lock starts -> ok anyway Moreover, for the cases were no key is hit before i3locks start, the following message is printed on the console (from which startx is launched): "WARNING: unhandled event of type 34" Hope this additional information can help. Kind regards Pascal Dormeau -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
