Note: DevPrivateKey is now pointer-to-int, which means
each key now needs to point to some global storage of
size at least sizeof(int).
(cherry picked from commit b6ab114212)
Add strncasecmp (as we're now using it) in case someone doesn't have it,
and also change strncasecmp args to be const, in accordance with
everything else.
(cherry picked from 11f9e35202 commit)
If input processing is frozen, only wrap realInputProc: don't smash
processInputProc as well. When input processing is thawed, pIP will be
rewrapped correctly.
This supersedes the previous workaround in 50e80c9.
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
(cherry picked from commit 37b1258f0a)
Patch by Joe Nall.
The option goes in the "extmod" subsection.
TODO: Make it easier for extension modules to handle their own options.
(cherry picked from commit b5f98fcea2)
This avoids creating a dependency on -current libpciaccess for
BSD systems other than OpenBSD (which don't otherwise need it).
(cherry picked from commit db248ffb84)
To recap: the original XC-SECURITY extension disallowed background "None" if
the window was untrusted. XACE 1.0 preserved this check as a hook function.
XACE pre-2.0 removed the hook and first abolished background "None entirely,
then restored it as a global on/off switch in response to Bug #13683.
Now it's back to being per-window, via a flag instead of a hook function.
Sorry about the megacommit, but this touches on a lot of stuff.
Get rid of XkbFileInfo, which was pretty seriously redundant, and move the
only useful thing it had (defined) into XkbDescRec. defined will be removed
pretty soon anyway. Is the compat map pointer non-NULL? Then you have a
compat map, congratulations! Anyhow, I digress.
All functions that took an XkbFileInfoPtr now take an XkbDescPtr, _except_
XkmReadFile, which returns an XkbDescPtr *, because people want to deal in
XkbDescPtrs, not XkbDescRecs.
We need to start breaking the XKB API to enforce sanity, so drag whichever
headers we need to do so into the server tree, as the client API is set in
stone, being part of Xlib.
In some cases (triggered by a key repeat during a sync grab) XKB unwrapping
can overwrite the device's realInputProc with the enqueueInputProc. When the
grab is released and the events are replayed, we end up in an infinite loop.
Each event is replayed and in replaying pushed to the end of the queue again.
This fix is a hack only. It ensures that the realInputProc is never
overwritten with the enqueueInputProc.
This fixes Bug #13511 (https://bugs.freedesktop.org/show_bug.cgi?id=13511)
(cherry picked from commit eace88989c)
