i3 is a tiling window manager for X11.
For more information about i3, please see the project's website and online documentation.
For information about contributing to i3, please see CONTRIBUTING.md.
improved screen locker
Home Page: https://i3wm.org/i3lock
License: BSD 3-Clause "New" or "Revised" License
i3 is a tiling window manager for X11.
For more information about i3, please see the project's website and online documentation.
For information about contributing to i3, please see CONTRIBUTING.md.
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)
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.
Reproduce:
Set i3bar to
mode hide
hidden_state hide
modifier $mod
On i3lock i3bar will be drawn on top of i3lock.
When i3lock is use with root account on KALI 2.0 you are not able to unlock with your password.
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 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
As soon as press a key, i3lock crashes. You can see my system info as well.
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.
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.
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:
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.
it should be possible to scale the background image to the size of the screen
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.
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.
It would be nice if the unlock indicator always be displayed, regardless of the state.
(Currently it is only shown after initial keypress)
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.
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?).
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.
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.
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)
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.
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 ?
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.
Tested on i3lock 2.6.
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:
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
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.
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).
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
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.
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)
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.
Looks like 2.7 was released, but the repository has no 2.7 tag.
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!
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.
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.
Is it possible to update the background image on change when ilock already launch?
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).
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 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?
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
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?)
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.
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.
shortcut to switch ime should work.
or ime should be disabled completely for locked screen.
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.
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?
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.
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.
When i3lock is shown I cannot change the keyboard layout with configured key combination. It happens with version 2.7
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.
Displaying PAM messages somewhere might be useful, it'd be nice reminder for 2FA PAM systems.
~ > sudo whoami
YubiKey for `david':
root
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?
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.
See #35. i3lock should display "locking..." while it is trying to grab the pointer so the user knows when the locking was successful.
Reproducing:
verifiying...
and wrong
: Type the right password.Reproducing another case:
verifiying...
and wrong
: Type any char.After the grace period, nothing makes visible, that the buffer is already filled with chars. There is no green ring.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.