Discard half-entered passwd after some inactivity

When you start typing a password and then wander off, let's discard that
attempt after a few minutes of inactivity (and turn off the monitors if
dpms is on).

This is a real actual case of making the software cat-proof: when my cat
treads over the keyboard at night, I don't want the monitors to shine
for the rest of the night.

Delay to turn off the screen after wrong passwd

Also add flag for number of seconds to wait for it.

When user cancels the password or enters a wrong one, i3lock will wait
for some time before putting the monitors back to sleep. By default it's
30 seconds, but this flag allows to control that.

Replace '1' with "EXIT_FAILURE"

Extract start/stop timer code to reusable funcs

Extract if(dpms) calls to wrapper functions

Turn on the screen on successful authentication

As described in ticket #1114, the screen may be left turned off on successful
authentication. This commit fixes this behaviour by turning the screen back on
after the authentication.

Fixes #1114

Re-raise i3lock when obscured in a separate process

This is cleaner than commit a305e62 (running authentication in a
separate process) because we don’t lose the feature that X11 will buffer
KeyPresses for us while the process blocks on PAM. See
http://cr.i3wm.org/patch/305 for the amount of code (and new known bugs)
that would have to be introduced to make a305e62 work.

Revert "Run authentification in different process"

This reverts commit a305e622a6cad3f9ba267d6810fee54b7c7c86c3.

In the next commit, the same functionality will be achieved in a cleaner
way.

Revert "Bug fix: Call clear_input() when the password is wrong."

This reverts commit 33d953fbdf4f8630e919643974f32ce6793c7c2b,
in preparation for reverting commit a305e62

Bug fix: Call clear_input() when the password is wrong.

clear_input() calls start_clear_indicator_timeout() to clear the
indicator after 1 second. This had as a result the screen to be cleared
when the "verifying…" message was showed, so the "wrong!" message didn't
show up when the password was wrong.

First bad commit: a305e62

Run authentification in different process

When having i3bar in “hide” mode, it could previously be brought up
while the authentication was running. This is not 100% fixed with this
change, but a lot better, as the normal “raise i3lock to the top”
behavior is not blocked now anymore.

fixes #895

Small improvements to manual page.

Use a bulleted list for the IMPROVEMENTS section. Fix some
grammar. Remove the use of "fuck" which may offend some people.

Bugfix: update the initial keyboard modifier state (Thanks lee, Ran)

This should make the numpad work correctly.

Add -e to --help

Add `-e` option to not validate empty password.

When the XF86ScreenSaver key is used to put a laptop to sleep (or to
trigger the screensaver), the key may "bounce" on resume. This is
annoying as i3lock will try to validate several empty passwords and
wait several seconds before accepting a legit password.

Some users may want to validate an empty password: PAM may rely on
other sources to unlock the screen, like the presence of a token or
the proximity of some Bluetooth device. Hence, we don't forbid this
possibility and provide an command-line option for users not willing
to validate empty passwords.

Use cairo_status_to_string for descriptive errors.

add xcb-atom to pkg-config calls

update changelog for 2.5

Set window name

Fix centering the indicator in the no-xinerama case

fix ctrl-u handling

Fix resetting the password after failed authentications

This has been broken by commit 661344.

Add ctrl+u password reset

Use ev_loop_fork after fork, this fix forking on kqueue based OSes

README: refer to cr.i3wm.org for patches

Limit the debug print to the actual password size

Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>

RGB color notation is 3-byte hexadecimal

Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>

Allow passwordless PAM conversations (e.g. fingerprint)

Allow XKB_KEY_XF86ScreenSaver as synonm for enter

This keysym is generated on convertible tablets by pressing a hardware
lock/unlock button.

remove support for NOLIBCAIRO, cairo-xcb is widespread by now

README: remove unhelpful comment about pkg-config

use libxkbcommon for input handling

Thanks to Ran Benita and Daniel Stone (the libxkbcommon authors) for
answering my questions and reviewing this code.

With this commit, input handling should be more correct with using less
code (in i3lock, that is).

bugfix: free(reply) to avoid memory leak

s/pam_message/pam_response/ (Thanks Tucos)

The previous code didn’t cause any issues since both types (currently!)
have the same size.

promote the "could not load image" message from debug to normal

only use mlock() on Linux, FreeBSD (for example) requires root

getopt_long returns int, don't cast to char.

On ARM, casting -1 to char turns it into something else. Fixes
argument parsing on ARM. Thanks Chipaca for reporting.

update changelog for 2.4.1

skip shift when getting the modifier mask (Thanks SardemFF7)

revert shift lock handling (broke uppercase letters)

With some layouts, this broke uppercase letters in your passwords.

I think that explicit shiftlock handling is unnecessary. X11 seems to do
it on its own. Here is what leads me to that conclusion:

  $ setxkbmap de
  $ xmodmap -e 'keycode 66 = Shift_Lock'
  $ xev

Now enter a character, say "a", then press CapsLk (which is now
Shift_Lock), then press "a" again. The event state is 0x1, thereby
undistinguishable from normal shift.

Bugfix: Correctly center unlock indicator after reconfiguring screens (Thanks xn)

Fixes: #712

remove debian/

The Debian packaging is now hosted on Debian servers at
git://git.debian.org/users/stapelberg/i3lock.git

This makes life easier for Debian people. It makes life harder
for you if you want to build a Debian package of the current
git version. Here is how you could do that now:

Build a tarball of the current git version:
mkdir ../i3lock-dpkg
VERSION=i3lock-$(git describe --tags)
git archive --prefix=$VERSION/ --output=../i3lock-dpkg/$VERSION.tar.bz2 HEAD

get the packaging:
cd ../i3lock-dpkg
gbp-clone git://git.debian.org/users/stapelberg/i3lock.git
cd i3lock
git-import-orig ../$VERSION.tar.bz2
dpkg-buildpackage

add .gitignore

add CHANGELOG file

Use (void) instead of () for functions without args (Thanks fernandotcl)

See also:
http://article.gmane.org/gmane.linux.kernel/1268792

The C compiler will handle (void) as "no arguments" and () as "variadic
function" (equivalent to (...)) which might lead to subtle errors, such
as the one which was fixed with commit 0ea64ae4.

Bugfix: fallback when the image cannot be loaded

If the specified file does not exist or is invalid, previously, the unlock
indicator wouldn’t show up at all, because the invalid surface was still used.

With this commit, i3lock will react like if you didn’t specify an image at all.

Only output text when in debug mode (fixes problems with xautolock)

Bugfix: Fix background color when using cairo (Thanks Pascal)

debian: update changelog for 2.3.1

fix compilation on some systems (Thanks badboy)

debian: fix packaging format to 1.0 for now

debian: remove duplicate priority field

manpage: add -u flag in synopsis

manpage: hyphen

debian: update packaging

README: also add libev to dependencies

document the dependency on libxcb-xinerama

Properly handle Caps Lock (Thanks Damien)

man page: mention xautolock

Bugfix: Copy the color depth from parent (root) window instead of hardcoding to 24 (Thanks hafron)

Added missing #ifndef NOLIBCAIRO

Needed to compile without libcairo.

Bugfix: Check for waiting X11 events before entering the event loop

Change the unlock indicator properly after pressing the 'escape' key

debian: add libxcb-xinerama0-dev as build-dependency

draw the unlock indicator in the middle of every screen

Implement Xinerama support (not used yet)

Fix a few memory leaks

Properly free timeouts, move one of the timeouts to unlock_indicator.c

remove the dead variable modeswitchmask

Properly free the reply of xcb_get_geometry

Refactor the unlock indicator into its own source code file

Fork after the window is visible, not before

change ALL the copyrights!

Lock the password buffer in memory, clear it in RAM after verifying

support ISO_Level5_Shift (Thanks roland)

Fix the timeouts for hiding the unlock indicator (Thanks Merovius)

Properly free X11 resources (fixes DoS bug) (Thanks Merovius)

Implement a visual unlock indicator

debian: update packaging to use dpkg-buildflags, i3lock.manpages

Makefile: add 'dist' target

Properly implement -h (fixes error message about unknown option)

Get rid of superfluous \n in --version

update debian/changelog

Bugfix: Properly detect the release of ISO_Level3_Shift (Thanks bacardi55)

Introduce --debug and some debugging options related to the Mode_switch / ISO_Level3_Shift thing

Correctly handle Mode_switch/ISO_Level3_Shift (Thanks bacardi55)

I tested this with the following experiment:
$ setxkbmap 'us(intl)'
$ xmodmap ~/configfiles/midna/Xmodmap
$ xmodmap -e 'keycode 38 = a A adiaeresis Adiaeresis o O'
$ xmodmap -e 'keycode 49 = ISO_Level3_Shift ISO_Level3_Shift ISO_Level3_Shift ISO_Level3_Shift'
Then, Mode_switch + a yields ä, but ` + a yields o.

In i3lock, these were swapped (Mode_switch + a yielded o, while ä was not
reachable at all). The comment in the code explains it

(See http://code.stapelberg.de/git/configfiles for the Xmodmap)

Bugfix: Don’t re-grab pointer/keyboard on MappingNotify (Thanks wilmer)

This fixes bug http://bugs.i3wm.org/545, where characters (of your password)
would rarely slip through when entering your password (especially) after
resuming your notebook from suspend to RAM.

The reason is that when resuming, X triggers one or more MappingNotify events.
At the same time, CPU load is high. This leads to a race-condition between the
ungrab and re-grab in which i3lock temporarily does not grab the keyboard.

One way to fix this is using xcb_grab_server() before and xcb_ungrab_server()
after the ungrab/re-grab. However, I think we actually don’t need to
ungrab/re-grab at all. I seem to have put that code in here by mistake – in i3,
we re-grab after MappingNotify, but there we only grab specific keys. In
i3lock, we grab the whole pointer/keyboard, so there should be no need.

If I’m incorrect and this breaks some subtle use-cases for people with strange
layout setup, at least we can properly document on why we need it, after we put
it back in ;).

manpage: mention arguments in OPTIONS section, too (Thanks TrickSTer)

Throw an error when specifying an invalid pointer argument (-p) (Thanks TrickSTer)

Fixed handle_screen_resize to build with NOLIBCAIRO enabled

handle screen resolution images and redraw the lock window

update debian packaging, update copyright

makefile: respect and use CPPFLAGS / LIBS (Thanks Kacper)

optimization: render to pixmap which is used as background for the window

Before this commit, the background color (white by default) was visible for
about 100ms until the image was drawn. This flickering is now eliminated.

Also, we don’t need to handle Expose-events anymore, as X11 will use the
window’s background pixmap automatically.

Mark handle_visibility_notify and handle_mapping_notify as static

update debian packaging

cleanup indention left-overs

bump copyright

Handle MappingNotify-events (Thanks Pascal)

use 'auth include login' instead of '@include login', the latter is debian-specific (Thanks mseed)