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.
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 37b1258f0a)
Composite uses an unmap/map cycle to trigger backing pixmap allocation
and cliprect recomputation when a window is redirected or unredirected.
To avoid protocol visible side effects, map and unmap events are
disabled temporarily. However, when a window is unmapped it is also
removed from grabs and loses focus, but these state changes are not
disabled.
This change supresses the unmap side effects during the composite
unmap/map cycle and fixes this bug:
http://bugzilla.gnome.org/show_bug.cgi?id=488264
where compiz would cause gnome-screensaver to lose its grab when
compiz unredirects the fullscreen lock window.
- The (x,y)-coordinates of the crtc were not being passed as xFixed values, which made it an obscure bug to find.
- Fix bug #13787.
(cherry picked from commit a48cc88ea2)
- This allows some compositing managers to work, even after randr12 has changed the root window size.
- Thanks to ajax for figuring out the best place to put this.
- Example:
- xf86RandR12SetMode() calls EnableDisableFBAccess().
- That calls xf86SetRootClip() which in turn calls ResizeChildrenWinSize().
- The final step is the call to PositionWindow().
(cherry picked from commit 70c0592a97)
In some weird cases we call this function when there is no SrvLedInfo on the
device. And it turns out null-pointer dereferences are bad.
X.Org Bug 13961 <http://bugs.freedesktop.org/show_bug.cgi?id=13961>
(cherry picked from commit d954f9c803)
(first_valuator + num_valuators) must never be larger than the number of axes,
otherwise DIX freaks out. And from looking at libXI, anything larger than 6 is
wrong too.
(cherry picked from commit 9f6ae61ad1)
Move size validation after depth validation, and only validate size if
the bpp of the pixmap format is > 8. If bpp < 8 then we're already
protected from overflow by the width and height checks.
(cherry picked from commit e9fa7c1c88)
Previously, we'd just keep num_sections at 0, which would break the
geometry and lead us to leak sections. Don't do that.
(cherry picked from commit 0137b0394a)
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)
(cherry picked from commit 50e80c3987)
If a device is already initialised (i.e. the virtual core devices) during
IASD, don't init them again. This fixes a leak.
(cherry picked from commit 1f6015c8fe62c28cfaa82cc855b5b9c28fd34607)
Initialise num_events to 1, so we always send a proximity event, and then
optionally valuator events. Also make sure mieq can deal with valuator
events sent after proximity events.
(cherry picked from commit 2dcfab37d38c0c72e9be7cc724047405c8029e88)