xf86CrtcRotate() is called by randr 1.2 drivers via xf86CrtcSetMode() or xf86SetDesiredModes()
during ScreenInit() at which point pScrn->pScreen is not set. If a user specifies a rotation
in their config file pScrn->pScreen is dereferenced and boom.
Requires inputproto 1.4.4 or higher.
(cherry picked from commit 591ef3c047)
Modified to use the numeric value of DeviceControlChanged instead of the
define, just so we don't bork out if someone rebuilds without updating
inputproto. This is a released server, after all.
Remove AEI check from configImpliedLayout as the setting isn't actually parsed
at this point anyway (written by Sasha Hlusiak).
Resurrect checkInput() and check for devices there if AEI is false (this also
creates the default devices if required).
Set AllowEmptyInput to enabled by default if hotplugging is enabled.
(cherry picked from commit bea743f3d629bafdc301f40e9c0bc11382dfe8bc)
Conflicts:
hw/xfree86/common/xf86Config.c
hw/xfree86/doc/man/xorg.conf.man.pre
We only have one set of default rules options in xkb. When the second keyboard
is brought up with Xkb options specified, these new options overwrite the old.
In future server generations, the rules used for the VCK are a mixture of the
default ones and ones previously specified for other keyboards. Simply
resetting the xkb default rules to NULL avoids this issue.
Reproducable by setting XkbLayout "de" and XkbVariant "nodeadkeys". In the
second server generation, the VCK has "us(nodeadkeys)". This again produces a
SIGABRT when the first key is hit.
I could not figure out why the SIGABRT happens. This patch is avoiding the
issue rather than fixing it.
(cherry picked from commit 5a3d06b8f4)
An integer overflow in the validation of the parameters of the
ShmPutImage() request makes it possible to trigger the copy of
arbitrary server memory to a pixmap that can subsequently be read by
the client, to read arbitrary parts of the X server memory space.
Lack of validation of the parameters of the
SProcSecurityGenerateAuthorization SProcRecordCreateContext
functions makes it possible for a specially crafted request to trigger
the swapping of bytes outside the parameter of these requests, causing
memory corruption.
Integer overflows can occur in the code validating the parameters for
the SProcRenderCreateLinearGradient, SProcRenderCreateRadialGradient
and SProcRenderCreateConicalGradient functions, leading to memory
corruption by swapping bytes outside of the intended request
parameters.
An integer overflow may occur in the computation of the
size of the glyph to be allocated by the ProcRenderCreateCursor()
function which will cause less memory to be allocated than expected,
leading later to dereferencing un-mapped memory, causing a crash of
the X server.
An integer overflow may occur in the computation of the size of the
glyph to be allocated by the AllocateGlyph() function which will cause
less memory to be allocated than expected, leading to later heap
overflow.
On systems where the X SIGSEGV handler includes a stack trace, more
malloc()-type functions are called, which may lead to other
exploitable issues.
ProcessOtherEvents was unconditionally stomping the root_{x,y}
co-ordinates provided by GetPointerEvents with those of the core
pointer, meaning that both root_{x,y} and event_{x,y} reported to
clients would reflect the sprite's position, not the position reported
by the device that generated the DeviceMotionNotify or the
DeviceButton{Press,Release} event in the first place.
For key events we still take the sprite's co-ords, as we're delivering
to the focus, which is the (VCP) sprite.
Not cherry-picked from master as MPX fixes this anyway, by taking the
co-ords of the sprite the device moves (be it visible or no).
(cherry picked from commit 8259d19f71)
