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 04211c3532)
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 bc2d516f16)
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 da973e962d)
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 9dfb525f6c)
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 cf20df39cc)
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 a56ef7aaa4)
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 a0284d577a)
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 f04c083869)
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.
