Age | Commit message (Collapse) | Author | Files | Lines |
|
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.
|
|
This reverts commit 5903b4c749c1136d0f3e91d5e6321b08c31da4bf.
And this one wasn't supposed to be pushed too.
|
|
This reverts commit 7cdef0d6fc3ec6705a61014b741a4c24dc60973b.
Nor was this one.
|
|
This reverts commit 9b62355847ce7df1ca144b4ebc9ff5c7286b573d.
This wasn't supposed to be pushed either.
|
|
enabled."
This reverts commit 153c6d48c655b3eca9a33b7487b238b42a4a3f8e.
How did this one end up on the branch? Sure as hell wasn't supposed to be
pushed.
|
|
Requires inputproto 1.4.4 or higher.
(cherry picked from commit 591ef3c047ab3597fef9d687205e99c254ff2040)
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
|
|
Could lead to some invalid pointers in the second server generation.
(cherry picked from commit ff3adf3e564d94fea18e48f966de40a7ded1279e)
|
|
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 5a3d06b8f42473cea3741dc722a775deaa2b73f6)
|
|
Based on the patch by Tomas Janousek.
Backported from master to server-1.4.
X.Org Bug 16179 <http://bugs.freedesktop.org/show_bug.cgi?id=16179>
(cherry picked from commit 26e7e69ab893d1f2b35213250ada40ec90944f62)
|
|
And update release date.
|
|
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.
|
|
Whatever. It doesn't have to be perfect.
|
|
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 8259d19f7155d82197ecc2aa16b316376c2dcb12)
|
|
|
|
It actually does help if a pointer is NULL rather than pointing to nirvana
when you're trying to free it lateron. Who would have thought?
(cherry picked from commit 7a97ca667405a42d008265c3a870210cc1da97dd)
(cherry picked from commit 0b0a09797302ac2171db5df20fc5110aafc8efbb)
|
|
(cherry picked from commit ab9b0b36ac8ac72fc48c0abd91a83de49a18313c)
(cherry picked from commit 4fa89fbe18c929e0d36305ab47e7e17841309ffd)
... and backported to 1.4 (back to no new devprivates and "amd" driver name)
|
|
ce50bfd3369686cfecee5a138bd84ef1107a249d)
|
|
The -wm (when mapped) option for the BackingStore support has been
causing the server to dereference a NULL pointer.
This has probably been the case since backing store has been
implemented on top of Composite.
It looks like (some of?) Composite didn’t expect its WIndowPtr
argument to be the root window.
In Composite’s compCheckRedirect() function we now avoid calling
compAllocPixmap() and compFreePixmap() when the pWin pointer’s
parent member is NULL, as is it the case with a server’s root window.
This addresses:
https://bugs.freedesktop.org/show_bug.cgi?id=15878
(cherry picked from commit 04211c3532ca078420e3745a5eac3d9de120bc32)
|
|
(cherry picked from commit 536f2ff5382aaaace3b55481e15366bb15d87801)
|
|
75 is just nonsense.
(cherry picked from commit db9ae863536fff80b5463d99e71dc47ae587980d)
|
|
Removing the device invalidates its ->next pointer. Copy it aside before
destroying the device.
(cherry picked from commit f52f6c5c7efc281f9ac204fbaa4f71383df7463d)
|
|
The result was that at 32bpp, pixmaps of width 8192 or greater couldn't be
created, due to treating a pitch value as a width.
(cherry picked from commit bc2d516f16d94c805b4dfa8e5b9eef40ff0cbe98)
|
|
This patch (and not setting HARDWARE_CURSOR_BIT_ORDER_MSBFIRST on big endian
platforms) fixes it for me with the radeon driver and doesn't break intel.
Correct patch this time :)
(cherry picked from commit da973e962d09854b571320dee7dd9569060bc39e)
|
|
|
|
|
|
|
|
|
|
|
|
(cherry picked from commit 7cdc19b29d93bf15cecfd6b69e269fab2501bca0)
|
|
KdInitOutput() used to enable Composite when it was disabled by default,
but now this hack prevents ``-extension Composite'' from working.
Remove it, as Composite is enabled by default anyway.
(cherry picked from commit 9dfb525f6c91acab5d1a65765a046bf9ee2aa082)
|
|
When something went wrong building a keymap, try to explain to the user
what it actually was, instead of the dreaded 'Failed to load XKB keymap'
catch-all.
(cherry picked from commit cf20df39cc78203d17b99223908af388ecbf7d0e)
Conflicts:
xkb/ddxLoad.c
|
|
Cross screen and clip the coordinates before updating the motion history
so that it will have the same contents as the events that are reported.
(cherry picked from commit a56ef7aaa4b6ac13c8181f68fc7dad3ca89e6973)
|
|
Relative events that generates both core and extention
events will have its axis cliped and screen changed by
miPointerSetPosition when the events are processed. For
absolute and non core-generating relative events the
axis must be clipped if we shouldn't end up completely
outside the defined ranges (if any).
(cherry picked from commit a0284d577aabea8406b72dd63773e341430ebe56)
|
|
Restore the rescaling code for x and y axis when generating
motion events.
(cherry picked from commit d9e23c4ff1607a62164b34717ef9afd352ce2b94)
|
|
Don't use a possitive value as a marker for if a max-value
is defined on the valuators. Use the existence of a valid
value range instead. This will also make it possible to
define arbitrary start and end-values for min and max as
long as min < max.
(cherry picked from commit f04c0838699f1a733735838e74cfbb1677b15dc4)
|
|
Send valuator information for all event types, not only for
MotionEvents and absolute button events.
(cherry picked from commit 12e532403210c15a25200ef448bfe9701735ab20)
|
|
Avoids auto-detecting dtrace is present on systems with the ISDN trace tool
named dtrace installed, but not the dynamic tracing facility named dtrace
|
|
Also, only restore an old signal handler if one was actually set
(prevents the server from dying on OS X).
|
|
|
|
Because our "popen" implementation uses stdio, and because nobody's stdio
library is capable of surviving signals, we need to make absolutely sure
that we hide the SIGALRM from the smart scheduler. Otherwise, when you
open a menu in openoffice, and it recompiles XKB to deal with the
accelerators, and you popen xkbcomp because we suck, then the scheduler
will tell you you're taking forever doing something stupid, and the
wait() code will get confused, and input will hang and your CPU usage
slams to 100%. Down, not across.
|
|
Assume AlwaysCore being set by default, just like the other options.
X.Org Bug 14256 <http://bugs.freedesktop.org/show_bug.cgi?id=14256>
(cherry picked from commit 5b8641a5fdc112c19e78ca2954878712e328d403)
|
|
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 37b1258f0a288a79ce6a3eef3559e17a67c4dd96)
|
|
(cherry picked from commit d502521c3669f3f22b94c39a64ab63bfd92c6a97)
|
|
(cherry picked from commit 3c337e18b933881e22b0d03312511f1d23a8640b)
|
|
Add support for DragonFly BSD, which is just the same as FreeBSD for all
of these cases.
(cherry picked from commit 0f87b41a432a6472a15ec0c9dee997e3bddbd0f2)
|