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.

Shouldn't need it.

We still try to reinstate grabs until we get them once per frame if we
ever get a NotifyUngrab.

NotifyUngrab is normal near startup (for releasing the L key when
locking via Ctrl-Alt-L in Xfce).

Shouldn't be needed anymore, as our events seem sufficient for that.

Also, add a signal handler for SIGTERM everywhere so killing xsecurelock
takes its children with it (and returns exit status 1).

Also, moved the datetime buffer to a local variable given it isn't used
across functions, fixed formatting, and loaded the LC_TIME locale so we
can show local time formats.

Fixes a warning.

Bring back the clamping, but instead explicitly query the root window size before building monitor structs.

The issue was that DisplayWidth()/DisplayHeight() values don't get
updated after XOpenDisplay(); the fix is querying the root window size
instead to update the auth window size.

The clamping is there to handle the (hopefully unlikely) case of a
screen being only partially in the root window (i.e. XRandR vs X11 core
inconsistency); it's no longer harmful once the bug is fixed.

Installation-wise, NetBSD works just like FreeBSD - you need to make
authproto_pam setuid root.

It's currently always based on git-describe - we may or may not want to
override that in the Debian packaging.

- Missing check for dup() return value; possible impact would be
  hard to track down authentication failures due to lack of logging.
- Uninitialized XSetWindowAttributes struct members (technically unused
  and thus a false positive, but cleaner this way nevertheless).