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)
