The old variable still works for compatibility if the new one isn't set.

Fixes #21.

It's then always shown on the screen with the mouse pointer.

Also added a macro SHOW_CURSOR_DURING_AUTH to actually show the pointer
- this is rather useless at the moment as auth helpers cannot receive
mouse events yet anyway. Still a nice proof of concept.

Add a feature to show cursor while auth is active (even though nothing actually receives mouse events yet).

Not in use yet, though, and there's no way for an auth helper to receive
clicks yet anyway.

This was enabled by Soumya's previous changes. Thanks!

I'd now really like to see an alternate auth helper that uses a toolkit
in single-window mode (following the monitor the mouse is on)... as
otherwise single-window auth is dead now (in fact, this version of
auth_x11 would work fine if passed the saver window ID instead).

Or maybe just a minor change to auth_x11 to behave as if there's only
one monitor all the time, while keeping the dialog on the current one...
let's see later.

- Auth window is still always on top.

- Auth window is now a child of the background window, not of the saver
  window.

- Thus, auth window now overlaps the saver window; thus all overlap
  protections for that window have been removed. In worst case something
  may now overlap the saver that we don't want; our protections still
  kick in if it also overlaps the background window (so there's only an
  issue if a saver is misbehaving).

Now auth helpers can create sibling windows; useful for multi-window
auth (be it for showing a windowed prompt on all screens while letting
the saver shine through, or be it for showing a "taskbar" at the bottom
to allow mouse based actions).

This change is compatible to existing auth helpers.

We only do this in order to restart the blanking timer; if savers
implemented a different protocol for this (e.g. SIGUSR1), this could go.

Don't want this to be confused with success.

Note: this can actually never happen on Linux.

Add basic support for playing sounds during the auth flow.

Use XSECURELOCK_AUTH_SOUNDS=1 to turn them off. Requires a working X11
bell (usually provided on Linux by the pcspkr kernel module).

Also, always run the player with a playlist of 256 videos; this strikes a
balance between having too many pauses between videos while not eating
too much memory in the player.

Replaces pull request #56.

README said it was enabled, but it's disabled by default.

Mainly because some people found it annoying to include the seconds there, but there's no portable way to remove them.

Fixes #57.

This allows easier building from outside a git repository; however, the
value should still either be based on a git revision or tag the build is
based on, or explicitly say that there is no correspondence to a
released git revision (e.g. by passing something like
VERSION='(ask pacman instead)') if necessary.

Fixes #59.

The only functional difference is that in XSECURELOCK_FORCE_GRAB=1 mode,
the new code will be holding a server grab while grabbing input even if
it detected another xsecurelock instance.

However, this difference is minor, and makes the code a lot more
readable.

Now compiles on Debian oldstable again.

Multiple screen lockers can interfere in various ways:

- First of all, log spam: only the first locker is usually able to lock at all. Any others will usually fail getting the required input grabs.

- Some lockers, e.g. light-locker, also have specific countermeasures against failing to lock and may interfere with xsecurelock. This has in the past caused issues such as having to unlock twice, having to unlock on a black screen because the graphics output broke, or losing all input focus after unlocking (yes, including alt-tab) and thus having a broken environment until clicking another window.

- Also, potential race conditions during startup of both at the same time might cause deadlocks (e.g. if one grabs mouse first and one grabs keyboard first, while retrying indefinitely).

- Even if they're not retrying indefinitely (xsecurelock isn't), this can slow down suspend to the point that systemd gives up and suspends before the screen is locked.

Looks better.

The previously used value - the background window - was simply wrong:
not only did it never receive events (as the grab is on the root
window), it also is not a child of the client window but it should be as
per Xlib Programming Manual.

Previous code waited one frame longer due to using the wrong variable.

Although the field we need does not correspond to any field to query, we
still must specify one or the call simply fails.

Fixes #46: "xsecurelock: XkbGetControls failed." error on Ctrl-Tab.

Should limit damage of the unmapping.

Also, optionally dump debug info about the first window unmapping which
helped (XSECURELOCK_DEBUG_WINDOW_INFO).

Instead of attempting to lock a Wayland session, just bail out. This prevents a false sense of security as trying to "lock" a Wayland session will by design only affect X11, not Wayland, clients.

Fixes #50.