* The GLcore interface is disposable
* GLcore is installed in DRI_DRIVER_INSTALL_DIR which is overloaded for
GLX_PROVIDER_INSTALL_DIR
(cherry picked from commit 567d389d47)
glcore gets linked with -ldl, -lpthread for s3tc and glapi
xserver needs
DLOPEN_LIBS - to dlopen the glcore dso
LD_EXPORT_SYMBOLS_FLAG - to export symbols for glcore to use
the ld flag is added to kdrive only when GLX is enabled, the net overhead for
Xephyr is ~155KB, could be reduced with --dynamic-list.
(cherry picked from commit efb723e166)
Conflicts:
configure.ac
Use only %di to name the PCI register to read/write, rather than %edi.
DOS is only expecting the base PCI config space anyway, and the BIOS
might be using the high bits of %edi.
(cherry picked from commit 9e5b3deafb)
Only do no-src-alpha optimizations for a RepeatNone source if we can
easily probe that we won't sample outside the edges of the source.
(cherry picked from commit 574c62e305)
This was only introduced in a later version of POSIX, so define that
version to get it from more conformant systems.
(cherry picked from commit 08073862f8)
Yes, this is a 486+ instruction and thus not strictly legal in vm86
mode, but enough BIOSes use it (looking at you VIA) that we might as
well implement it.
(cherry picked from commit c8d066a151)
... instead of creating pixmaps that only fb knows about, which will
have no devPrivates for any other subsystem and thus cause havoc if
(when) they leak out.
(cherry picked from commit b55fbca4f0)
Say Option "XaaOffscreenPixmaps" to turn them back on.
Apropos of bugs #13795 and #15098. Not yet applied to master as this wants
a proper solution someday, but then, those bugs aren't closed yet either.
In the single output enabled case we never enter the loop and test
never gets set and so we fail to match a good mode.
This was causing my 2560x1600 to end up at 2048x1536.
GNU/kFreeBSD defines __FreeBSD_kernel__, but not __FreeBSD__.
Unify preprocessor conditionals between variable declaration and use.
Debian bug #482550.
(cherry picked from commit e6cbb1e11e)
The HAL spec says that input.xkb.{rmlv}* can be sent, but if the user
specifies a X-specific {rmlv}, then this is overridden through the use of
input.x11_options.Xkb{RMLV}.
However, the way how the server parses options--by ignoring capitalisation,
underscores and spaces--the HAL and the x11_options would override each other.
So we simply filter the options, letting Xkb{RMLV} override xkb_{rmlv} and
only actually add them to the device after parsing _all_ options.
* rmlv ... rules, model, layout, variant
See Bug 13037 <http://bugs.freedesktop.org/show_bug.cgi?id=13037>
(cherry picked from commit fc35d1e3be)
(cherry picked from commit ff013b0da4)
Parse "input.x11_options" and pass every key/name pair to the driver.
Remove check for input.capabilities, because that's part of the fdi files.
Thanks to Dustin Spicuzza <dustin@virtualroadside.com> for the patch.
(cherry picked from commit 47eb658e80)
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.
(cherry picked from commit 95d162c438)
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.
(cherry picked from commit 063f18ef6d)
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.
(cherry picked from commit c5f69b297b)
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.
(cherry picked from commit 5257a0f83d)
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.
(cherry picked from commit 9171206db3)
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.
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).
