Displaying PAM messages somewhere might be useful, it'd be nice reminder for 2FA PAM systems.

~ > sudo whoami
YubiKey for `david': 
root

What happens

When i am running a virtual machine in VirtualBox, and lock the screen,
while VirtualBox is focussed (eg. with keyboard shortcut), i3lock locks the screen,
but when trying to input the password, i3lock crashes.

i3lock infos

i3lock version:
i3lock: version 2.8 (2016-06-04) © 2010 Michael Stapelberg

i3lock debug output:

[i3lock-debug] device = 3
[i3lock-debug] found Xinerama screen: 1600 x 900 at 0 x 0
[i3lock-debug] scaling_factor is 1, physical diameter is 190 px
[i3lock-debug] Watching window 0x04200003
[i3lock-debug] Read event of type 15
[i3lock-debug] Read event of type 15
i3lock: Cannot grab pointer/keyboard
[i3lock-debug] Read event of type 18
[i3lock-debug] UnmapNotify for 0x04200003

GIF

As soon as press a key, i3lock crashes. You can see my system info as well.

Sometimes calling i3lock causes the screen to display garbage (garbage sometimes also meaning sensible data from the graphics memory). Pressing any key instantly fixes the issue.

I think that this might be caused by #13 (fix for #12). I reverted the patch locally and will test to see if the problem disappears. I blamed a graphics driver update first, but given that this is the only time this ever happens and the fact that it makes sense that it could have to do with #13, it's worth looking into.

When i3lock is shown I cannot change the keyboard layout with configured key combination. It happens with version 2.7

Reproduce:
Set i3bar to

mode hide
hidden_state hide
modifier $mod

On i3lock i3bar will be drawn on top of i3lock.

1. Open a right-click menu in some program.
2. Launch i3lock with relevant keybinding.
3. Lock screen appears for a few seconds before dropping user back to session.

Tested on i3lock 2.6.

After I enter a wrong password, while displaying the 'wrong' message, I cannot submit a password by pressing the return key. I have to wait for the 'wrong' message to time out before pressing the return key to submit my password.

What I am used to is that when I enter a wrong password, I can 'queue up' the right password immediately after and as soon as 'verifying' is done for the first (wrong) password it will start verifying the second (right) password and unlock. Whereas now I have to wait for the wrong message and only afterwards press the return key to unlock my pc.

Arch Linux 4.2.5-1
i3lock: version 2.7 (2015-05-20)

I use /usr/bin/i3lock -d -I 5 -e -f
When hitting a key screen wakes up and sleeps again after 5s.

When moving the mouse it takes forever (more than 5s) until dpms makes screen sleep

When hitting a key after mouse was moved, dpms kicks in 5s later, like requested.

I have three layouts on my desktop. Two of them have cyrillic symbols (RU, UA). Also I have a really complicated password in English. So for me it's very confusing to guess "What is the current layout when I'm typing unlock password?". I know at least one more person who has the same issues as I.

Thanks.

Looks like 2.7 was released, but the repository has no 2.7 tag.

Because of this reason, i3lock can't handle passwords with accents (e.g. á, ë) or other complex glyphs which are composed with 2 or more key presses.

This make the application pretty unusable for that kind of passwords.

The issue affects the latest release of i3lock and has not been tested on previous releases.

I use i3 and i3lock on xubuntu 14.04 (Trusty Tahr) with 2 displays:

1. Laptop display
2. External display placed as "right of" the laptop display

If the external display is rotated 90° to left, i3lock does not draw its overlay in a good way on it. In particular, the overlay is perfectly drawn on the laptop display but it only covers 50% of the height of the external display.
Since only half of the external display is "locked", i3lock does not completely secure the underlying tiles/windows.

However, as soon as a key is pressed and the password validation routine starts working, the new overlay containing the login animation finally occupies the entire screen.
To have an unsecure lockscreen again it is enough to login with the correct password and then lock the screen again.

In raise_loop i3lock is waiting for events on its window. On a few occasions this has caused i3lock to not exit on my system after unlocking. At best, this causes stray processes and at worst it prevents locking the screen when external scripts check whether the previous i3lock run terminated.

By analysing the running i3lock process using gdb I have found the window it is waiting for doesn't exist anymore (Obvisouly, this is expected as my session is unlocked). I'm going to run i3lock with --debug from now on so I get a better idea of what's going on.

I can't reproduce this yet.

If I run i3lock -d, the screen turns off, but if I run i3lock -d -c 000000, the screen turns off and then turns on back after about a second.

Arch linux, Xorg 1.17.2, i3lock 2.7.

Due to the way active grabs work in X, we currently have a loop that tries the grab for some time before giving up. This causes locking the screen to fail when, for example, context menus are open etc.

While this proposal does not solve this problem, i3lock could have a better shot by forcing a release of active grabs by sending XF86Ungrab before grabbing the keyboard. This will only work if the user has this feature enabled (setxkbmap -option grab:break_action). If that's the case, all active grabs will be released.

On the other hand, if the user has this enabled, they of course also run the risk of someone breaking i3lock the same way. But it's not up to i3lock to decide whether the user has this enabled or not – if they do, we can make use of it.

i3lock could have an individual lockscreen image for every screen.
This could be achieved by using the -i flag multiple times or once with multiple paths.

While the password is locked, pass the special keys to play/pause/mute/... the music to i3.
You don't have to type the password anymore to access the mediaplayer.

Duplicate in i3 repo from november, never reported here and not fixed: i3/i3#2057

Steps to reproduce:
dmenu_run; sleep 1; ./i3lock

Expected Result: i3lock displaying over dmenu and locking the screen

Actual Result: i3lock displaying under dmenu and crashing after about one second

Tested with 2.7-9-g59705b0 (2015-12-25) and 2.7 (2015-05-20)

This feature will help differentiate between i3lock with black background, blank DPMS, monitor warming up, monitor standby, et cetera....

If I'm using xautolock to suspend the machine (or suspend it manually). I can't determine easily when I'm back on i3lock without pressing something to trigger the circle and unlock the password.

If I don't press anything for a while, the machine will quickly suspend again... I would not press anything because I'm either waiting for the monitors to warm up once the connection has been made and possibly because i3lock's background remains black.

I understand that this can be easily solved by using different background color but I wish to keep my background pure black for a sake of simplicity. I wish to have an option to make i3lock more consistent by always displaying the circle regardless of its feedback (or lack of one). Here's a mockup.

Reproducing:

1. $WrongPW + Enter
2. While verifiying... and wrong: Type the right password.
3. After the red ring fades away, just press Enter again and you're logged in.

Reproducing another case:

1. $WrongPW + Enter
2. While verifiying... and wrong: Type any char.
3. After the red ring fades away, type the correct password and press enter. -> Login attempt incorrect.

After the grace period, nothing makes visible, that the buffer is already filled with chars. There is no green ring.

I am running i3 on Ubuntu 14.04. If i3lock is run with sudo, it always says the password is incorrect (if it is run without it, it runs perfectly). As per #43 , I compiled and installed from the git source but it still did not work. Is there anything I can do?

Hello,

I wrote a udev rule to lock the screen using i3lock whenever I remove a given pendrive (a yubikey used for authentication in my case). The screens lock properly, but after a while (around 5~10minutes), i3lock unlocks itself. The screens stay off, but if I move my mouse or type anything, they turn on and I can use my session without entering a password. There doesn't seem to be a crash or weird happening (see outputs below).

I haven't found anyone else seeing this problem. Maybe it's due to yubikey-pam, maybe i3lock and maybe I'm doing something wrong. I think the problem is with i3lock because:

1. The screen locks properly at first (so udev is launching i3lock properly)
2. To unlock with the yubikey, I still need to press enter, but when it unlocks itself, I just need to move the mouse

If there's anything else I can provide to help, just tell me.

Anyhow, here is the result of i3lock --debug launched from udev:

[i3lock-debug] device = 3
[i3lock-debug] found Xinerama screen: 1920 x 1080 at 0 x 1050
[i3lock-debug] found Xinerama screen: 1080 x 1920 at 3840 x 0
[i3lock-debug] found Xinerama screen: 1920 x 1080 at 1920 x 380
[i3lock-debug] scaling_factor is 1, physical diameter is 238 px
[i3lock-debug] device = 3

And the result of ltrace -f of i3lock launched from udev (no --debug) is attached:
i3lock.ltrace.zip

EDIT: attach trace as zip for readability

See #35. i3lock should display "locking..." while it is trying to grab the pointer so the user knows when the locking was successful.

When I enter the wrong password to unlock the screen, I have problems with the next try. I have to press backspace or esc to delete the wrong password, so I can enter the new one. If you don't know the workaround, you're not able to login.

I'm using the current Version from the Arch Linux Repository:

$ i3lock --version
i3lock: version 2.7 (2015-05-20) © 2010 Michael Stapelberg

If I try to enter a number on my numpad while numlock is enabled nothing happens. Only if i deactivate numlock it detects the number correctly but any other application does not.

After finding out about i3/i3#1993 I checked i3lock as well. While building does not fail here, we end up with

$ ./i3lock --version
i3lock: version  () © 2010 Michael Stapelberg

Is it possible to update the background image on change when ilock already launch?

I want to be able to change volume, or access to MediaPlayer even when system is locked. Is there any way to allow these kind of shortcuts in i3lock?

The section of i3lock's man page regarding the -I --inactivity-timeout flag is unclear on the syntax. Based on error messages, I've gathered that the flag requires an int to supply the time after which the screen disappears, however this was not evident at first in the man file. I'd suggest simply adding the underlined 'seconds' after the -I switch's syntax, to clarify that it's necessary.

I would like to use i3lock with blueproximity and have my laptop unlock when my phone is within a certain distance.

I tried using the following script:

#!/bin/bash
LOCKFILE=/home/raphael/.i3lock
if [ -e $LOCKFILE ]; then
    kill `cat $LOCKFILE`
    rm -f $LOCKFILE
fi

where /home/raphael/.i3lock is created with:

#!/bin/bash
LOCKFILE=/home/raphael/.i3lock
i3lock --nofork --color=A0A0AA &
echo $!>$LOCKFILE

However the unlock script fails with:

unlock: line 6: kill: (8106) - No such process

I was hoping using the --nofork option would return the right pid but it doesn't seem like it.

How can I unlock the screen using scripts?

At the moment it seams i3lock only handle the auth stack.

If pam_krb5 is used for authentication, the auth stack stores the credentials in a temprary file (/tmp/krb5_pam_XXXXXX). During session stack (pam_sm_setcred), the credentials are moved to its final location (/tmp/krb5cc_UID_XXXXXX) and the environment variable KRB5CCNAME will be set.

Its not a big deal and anyone who spends 5 seconds reading the build make message will know whats missing but the list in the readme of required libraries is missing libxcb-dpms0-dev. At least this is the case for my Ubuntu 14.04 LTS box.

If an application (in my case for example evolution mail when it displays a notification for an event) opens a new window while my X session is locked with i3lock, this newly created window is shown on top of i3lock and i3lock does not receive subsequent keyboard input. Consequently, my screen content is visible, which shouldn't happen while the screen is locked, and I can not unlock the screen because i3lock does not react to me entering the password.

The loss of input focus is not reproducible and only happens sometimes, but the covering can be triggered easily by executing i3lock && sleep 10 ; evince and waiting for 10 seconds. evince appears on top of i3lock.

I am using i3lock: version 2.7 (2015-05-20) © 2010 Michael Stapelberg from the Debian testing package.

Description

I use ibus Arabic ime (m17n) and when I enter the lock screen, there is no way to switch back to english input method so it's impossible for me to input correct password. In order to fix this, I switch to another tty and disable i3lock on start up and reboot.

Steps to Reproduce

1. activate ibus ime (non english input method .. say arabic ime for example)
2. lock the screen
3. impossible to turn off arabic ime from locked screen ( so: cannot input correct password)

Expected Results

shortcut to switch ime should work.
or ime should be disabled completely for locked screen.

Hello,

Just today I upgraded to i3lock 2.6, and right away I notice a huge hassle, which made me switch away from xscreensaver a long time ago; and now it's here too.

Some background: I have two keyboard layouts on my computer: the regular Latin, and Cyrillic. My password is all Latin letters + digits.

Back on i3lock 2.4 it did not matter which keyboard layout I had selected on my desktop before going into the lock mode. Whatever I typed on the lock screen, was accepted by i3lock as Latin characters. I enter my password, the screen unlocks, all is well.

Enter 2.6. Now apparently the keyboard layout from the desktop is remembered also while in the i3lock mode. So after coming back to my computer, I enter my password, it says "bzzzt wrong!", I enter once more, wrong again, I figure I can't be mistyping so repeatedly and then realize -- dammit, what I type now goes to i3lock as Cyrillic! I press the layout switch keys, then retype my password once more, and finally it's typed in the Latin layout and accepted.

So I am checking change logs, and of course for "2013-06-09 i3lock 2.5" it says: "• NEW DEPENDENCY: Use libxkbcommon for input handling. This makes input handling much better for many edge cases." You probably think it's an amazing feature which made life for many people easier -- except for us, the actual users of multiple keyboard layouts. Such misfeatures which actually end up being the users' worst nightmare, it just makes me want to cry. Why one after another (first xscreensaver, now i3lock) you all step into the same pitfall.

Now one solution for this whole thing would be to add the current keyboard layout indicator to the lock screen. Which is how e.g. Windows does it. But I would argue it's not the best one. I believe barely anyone uses non-Latin (Cyrillic) passwords here, due to possible issues with inability to enter Cyrillic on certain consoles, or wrong layouts, encodings problem, etc. Also I like that i3lock is as simple as possible (possibly contributing to security), not having any extra widgets on the lock screen etc.

My suggestion would be to return i3lock to the original mode of operation (i.e. Latin only input), and adding an option to change this behaviour if the user wants.

As for me I guess I can downgrade to 2.4, it seems to still work on Debian Jessie. And of course after downgrade the problem is immediately and 100% solved. But I hope you will tell me there is hope and I won't have to keep using this old version forever from now on.

This is a migrated issue from i3/i3. See i3/i3#1117. Original post:

[Originally reported by samanthad@…]
(Version 2.5 of i3lock displays a stuck cursor over the lock image when no cursor should be visible.

To replicate, set i3lock to start after a delay then switch to a virtual terminal (like TTY2). Wait for the delay to expire and i3lock to start then switch back to the X session. Cursor should be visible but frozen.

The cursor remains visible when the unlock indicator appears. Once unlocked, if the mouse has been moved, the pointer will appear in a new location, unrelated to the one displayed while stuck.

I used the command sleep 10; i3lock to test.

Note that if i3lock is called with either '-p default' or '-p win' options, i3lock performs normally. Cursor only becomes stuck and visible when the cursor should be hidden.

The test machine's graphics hardware is an AMD E-350 APU. I use the "radeon" driver.

I have replicated the bug using version 2.5-11-g6c34f6a of i3lock. I have also replicated the bug using i3lock under Openbox.

The included logfile is produced with version 2.5-11-g6c34f6a.

Hi there!

I would suggest to not accept any input during the verifying process. Some days ago, I found myself unable to login because a funny coworker spamed the lockscreen with false inputs (hitting a single button and enter for a few hundred times..). Hence the login was unavailable until every input was tested (.. denial of service attack?).

Generally I really appreciate the simplicity of i3lock, so I'm sorry to ask for another feature. That said, there is a Windows pointer. :)

Title is self explanatory. This fork does it like so:

--insidevercolor=rrggbbaa -- Inside of the circle while the password is being verified
--insidewrongcolor=rrggbbaa -- Inside of the circle when a wrong password was entered
--insidecolor=rrggbbaa -- Inside of the circle while typing/idle
--ringvercolor=rrggbbaa -- Outer ring while the password is being

For the purposes of visual matching, but also to make the unlock indicator actually useful for people with protanopia, deuteranopia, etc. (red-green color blindness).

it should be possible to scale the background image to the size of the screen

Description

Given a dual-monitor system with i3lock active, when unlocking the screen my main monitor continued to display the 'verifying' circle and was unusable. My second monitor was still accessible (although I restarted the system instead of seeing if killing i3lock worked).

Behaviour

• main monitor displays verifying
• main monitor displays the i3bar
• main monitor is inaccessible
• second monitor is unlocked and usable
• keyboard shortcuts don't work when main monitor is in focus

Expected behaviour

• i3lock exits and releases all control

Reproducing

This error occurred randomly after using i3lock hundreds of time before. Unfortunately I have no steps to help reproduce the error as this has only happenned to me once

I want to use jpg files on my lock screen.

Is JPEG support deliberately excluded, or simply not included because it doesn't come with Cairo?

It looks like there's cairo_jpg which would provide the necessary functionality.

Is that something that could be added to i3lock? (Or is there a fork which supports JPEGs?)

When i3lock is use with root account on KALI 2.0 you are not able to unlock with your password.

Hello guys,

First of all, thanks for this simple but perfect locker !

As a vim user, I like not to move my hands, for exemple to access the Enter key.. I usually use Ctrl-J to validate something, and would like to have that feature in i3lock also.

So for exemple, I type my password as usual, then I type Ctrl-J to validate the password

I went through the code, and think that there is something to change arround thoses lines :
https://github.com/i3/i3lock/blob/master/i3lock.c#L369

What do you think about this ?

Hi there,
I am using i3lock with a systemd service to secure my unlock by using the fork option,
it work well, but I would like to send a command just after the end of i3lock.

I made a wrapper (here: https://github.com/GuillaumeSeren/i3lock-wrapper), it work's for simple lock,
but it break the the suspend if I use it, so I used my wrapper for lock / and just i3lock for suspend.

So my question is, do you know a better way to do it ?

In my opinion, it would be great to store a command and to launch it / fork it after the end of i3lock, do you think it can be done ?

Guillaume.

When screen is locked using i3lock new notifications from Chromium appear on the screen above i3lock and are readable by any passers-by.

This happens whenever Chromium is running, the screen is locked, and Chromium displays a pop-up notification.

Possible workarounds are just disabling Chromium notifications, but in my mind i3lock should be blocking stuff like this. I haven't done extensive testing to see if spawning other types of windows or window-like things (while the screen is locked) will result in similar behavior.

Type in your correct password, press enter: OK.
Type in your correct password, press Del, press enter: Bad.

i3lock accepts the Del as another character of the password. It should either do nothing or be an equivalent to the backspace.

i3lock: version 2.7 (2015-05-20) © 2010 Michael Stapelberg

Merry Xmas.

Found using Valgrind.

==16263== Syscall param writev(vector[...]) points to uninitialised byte(s)
==16263==    at 0x6C03310: __writev_nocancel (in /usr/lib/libc-2.23.so)
==16263==    by 0x5DA0DA8: ??? (in /usr/lib/libxcb.so.1.1.0)
==16263==    by 0x5DA119C: ??? (in /usr/lib/libxcb.so.1.1.0)
==16263==    by 0x5DA18F6: ??? (in /usr/lib/libxcb.so.1.1.0)
==16263==    by 0x5DA2522: ??? (in /usr/lib/libxcb.so.1.1.0)
==16263==    by 0x5DA25A0: xcb_wait_for_reply (in /usr/lib/libxcb.so.1.1.0)
==16263==    by 0x403D11: grab_pointer_and_keyboard (xcb.c:181)
==16263==    by 0x405AAA: main (i3lock.c:957)
==16263==  Address 0xc84349d is 4,749 bytes inside a block of size 21,152 alloc'd
==16263==    at 0x4C2C947: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16263==    by 0x5DA075B: xcb_connect_to_fd (in /usr/lib/libxcb.so.1.1.0)
==16263==    by 0x5DA4490: xcb_connect_to_display_with_auth_info (in /usr/lib/libxcb.so.1.1.0)
==16263==    by 0x405771: main (i3lock.c:860)
==16263==  Uninitialised value was created by a heap allocation
==16263==    at 0x4C2ABD0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==16263==    by 0x57726B4: xcb_image_create (in /usr/lib/libxcb-image.so.0.0.0)
==16263==    by 0x577363A: xcb_image_native (in /usr/lib/libxcb-image.so.0.0.0)
==16263==    by 0x5773865: xcb_create_pixmap_from_bitmap_data (in /usr/lib/libxcb-image.so.0.0.0)
==16263==    by 0x403E96: create_cursor (xcb.c:241)
==16263==    by 0x405A85: main (i3lock.c:955)

Former discussion here: https://faq.i3wm.org/question/5839/i3lock-how-to-disable-redraw/

start of the idea/problem here: http://redd.it/328e18

If you read this threads, you'll see I'm drawing some status information onto i3locks window with conky. The unlock indicator is disabled, so in theory there should be no need for a screen redraw (at least I see no technical need for this). As a result of redrawing the screen, my conky vanishes and reappers on every keypress (which looks strange and ugly) - happens with conky no matter if I used double buffer or not.

Therefor, I'd like to request an option to disable the redraw. Thanks.

It would be nice if the unlock indicator always be displayed, regardless of the state.
(Currently it is only shown after initial keypress)

When I type the wrong password in i3lock (frequently!) there is a considerable delay before I am allowed to retype my password.

I know that this is done for security reasons, but it would be nice if the delay were configurable so that I could shorten it.

Even better would be exponential backoff so that the the first few times I mistype my password (normal) there is little delay, but after multiple repeated wrong passwords (uncommon) the delay is longer.

Thanks!