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)
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).
The problem happens if Monitor/Card combo doesn't provide EDID info,
and the XFree86-VidModeExtension extension is used.
Signed-off-by: Peter Hutterer <peter@cs.unisa.edu.au>
(cherry picked from commit c8af7ce35a)
Use dummy config functions to replace those from config/config.c, and
therefore do not link Xprt with $CONFIG_LIB.
Works around an endlessly spinning loop in dix/dispatch.c::Dispatch()
(WaitForSomething() not waiting) when built with dbus, which was
causing Xprt to use 95% cpu.
(cherry picked from commit 2a3d1421e0)
(cherry picked from commit 4e2c6dbabdbbaaca213fd08edd422de15d0900cc)
required because of commit 7c0709a736,
which made requestingClient in dix specific to Xprint only.
Add to XPRINT_LIBS in hw/xprint/Makefile.am in front of
$(XSERVER_LIBS) to override definitions in libdix.la for standard xservers.
Follows 571206832d (providing -DXPRINT
to xprint subdirs).
Note it may be possible to restructure the code so that
requestingClient is stored elsewhere than in dix. See discussions
following http://lists.freedesktop.org/archives/xorg/2008-March/033844.html
If this is done it may be possible to revert this commit (if not 571206...).
(cherry picked from commit 966ae1781f)
-DXPRINT had only been set for Xprt in hw/xprint/Makefile.am
After commit 7c0709a736 it is also
required for ps/PsArea.c and PsFonts.c to ensure ‘requestingClient’ is
defined, so make it a global Xprint definition in configure.ac.
(cherry picked from commit 28a6719fd486d9a9cecad0b057d9ea7c59c66055)
(cherry picked from commit 571206832d)
* Make sure available areas are considered to have no eviction cost. This seems
to help for https://bugs.freedesktop.org/show_bug.cgi?id=15513 but I'm afraid
that may just be coincidence.
* Only calculate eviction cost of each area once for each eviction pass.
Safeguard against potential (though unlikely) division by zero.
* Cosmetic enhancements: Name eviction cost related variables 'cost' instead of
'score' to emphasize that smaller values are better, update Doxygen file
comment to the way eviction works now.
(cherry picked from commit 6c95fae1e9)
This allows using PanoramiXTranslateVisualID to test whether a given visual made
it through PanoramiXVisualConsolidate.
(cherry picked from commit 8b3d26f5b6)
If the monitor isn't reduced-blanking (either through EDID logic, or
config file setting), then remove RB modes from the default pool. Any
RB modes from the driver and config file pools will stick around though;
you asked for them, you got them.
(cherry picked from commit 0178b6a4ab)
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 first guess used to be "is the preferred mode for one output the
preferred mode on all outputs". Instead, do "find the largest mode that's
preferred for at least one output and available on all outputs".
(cherry picked from commit 459f34b089)
Old logic was just the first one that happened to have an associated
CRTC. The new logic tries to find one that's definitely connected, has
probed modes, and has the largest candidate mode.
(cherry picked from commit 96111c1547)
The first fbconfig which has a depthbuffer > 0 and doublebuf is choosen
when associating fbconfigs with the visuals, indepenent of stencil bits.
This happens to work ok on intel as there all fbconfigs with a
depthbuffer > 0 also have stencil bits.
This patch fixes this by first trying to get a fbconfig for default X visuals
with both stencilbuf, depthbuf and doublebuffering, and if that fails fallback
to trying to get one with only a depthbuf and doublebuffering.
(cherry picked from commit f6e22d69af)
Create a new exported global variable, XineramaVisualsEqualPtr. Use this
pointer to decide whether two visuals are equal during visual consolidation.
This pointer can be wrapped, which allows drivers and extensions to control
which visuals are consolidated. A wrapper can reject the visuals without
calling down, but must call down and return that result if it deems the visuals
equal. This ensures that all layers agree that the visuals are equal.
Pass the screen of the other visual into the VisualsEqual callchain.
Don't free PanoramiXVisuals since we need it for PanoramiXTranslateVisualID.
Don't skip the first visual on the other screen in PanoramiXMaybeAddVisual.
Skip the loop in PanoramiXTranslateVisualID if screen is 0.
(cherry picked from commit c50b5d9789)
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)
Since glyphs are stored in pixmaps now, they can make their way into VRAM,
which invalidates a bunch of fast-path assumptions in the XAA code. Thus
you end up doing color-expands or WriteBitmap from la-la land and your
aliased glyphs go all funny.
Since XAA isn't ever growing the ability to do sane glyph accel, just force
glyph pixmaps into host memory by catching them at CreatePixmap time.
(cherry picked from commit 718652eaf9)
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)
Thanks to Owen Taylor for root-causing this one.
If a TreatAsTransparent window has any area in the borderClip, that will be
added to the totalClip region for use by other windows. That's wrong.
Instead, simply empty the borderClip for TreatAsTransparent windows right up
front.
(cherry picked from commit 6c1accce87)
