This extension provided bug-compatibility with pre-X11R6, but has been
stubbed out in our server since 2006 to return BadRequest when you actually
asked for it.
A few pieces of code were abusing this define for other purposes, which are
converted to #ifndef DEBUG instead. There should be no ABI consequences
to this change.
The rationale is that having the define in xorg-server.h also disables
assert() drivers, which is unexpected, and also difficult to avoid since
xorg-server.h is included in their config.h, and you can't put a #undef in
config.h. As for removing it from the server instead of moving it to an
internal header, we probably shouldn't have unnecessary assert()s in
critical server paths anyway, and if we do we could #define NDEBUG in the
specific cases needed.
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>
Evaluating the address of a BoxRec as a boolean gives this warning:
i830_driver.c:2317: warning: the address of 'ScreenBox' will always
evaluate as 'true'
which is pretty annoying. This patch compares the address to NULL to
avoid the pointer->bool conversion and gets rid of the warning. Seems
like a lame hack, but the warning is worse.
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)
