The fixes for the composite reallocation failure, were freeing the oldpixmap
straight after reallocating the new one, however this led to some wierd
effects in e16 compositing, and I think in a few other places. This patch
moves the freeing of the pixmap into the post wrapped stage. I'm not sure if
we are actually better off breaking ABI and adding another callback from the
ConfigureWindow to composite to make sure the old pixmap is always freed,
but this should be satisfactory as we should always hit one of the freeing
paths or else its a bug in the DIX.
bug: https://bugs.freedesktop.org/show_bug.cgi?id=28435
Reported-by: Andrew Randrianasulu <randrik@mail.ru>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This patch only changes the API, not the implementation of the
devPrivates infrastructure. This will permit a new devPrivates
implementation to be layed into the server without requiring
simultaneous changes in every devPrivates user.
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Tiago Vignatti <tiago.vignatti@nokia.com>
This is a combination of a huge mechanical patch and a few small
fixups required to finish the job. They were reviewed separately, but
because the server does not build without both pieces, I've merged
them together at this time.
The mechanical changes were performed by running the included
'fix-region' script over the whole tree:
$ git ls-files | grep -v '^fix-' | xargs ./fix-region
And then, the white space errors in the resulting patch were fixed
using the provided fix-patch-whitespace script.
$ sh ./fix-patch-whitespace
Thanks to Jamey Sharp for the mighty fine sed-generating sed script.
The hand-done changes involve removing functions from dix/region.c
that duplicate inline functions in include/regionstr.h, along with
their declarations in regionstr.h, mi.h and mispans.h.
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
Since reallocating the backing pixmap can fail, we need to try and do
it before any other side effects of reconfiguring the window happen.
This changes the ConfigNotify hook to return status, and moves the
composite window reconfiguration wrappers to ConfigNotify. They all
basically did the same thing, so we can drop the MoveWindow,
ResizeWindow, ChangeBorderWidth wrappers, and allow ConfigNotify to do
all the work. If reallocation fails we fail before we send any
confiureNotify events, or enter the area we can't recover from.
The only place we now enforce 32k limits are in EXA/UXA/fb, so drivers
that don't use this should probably deal with it in their pixmap
allocate if they don't already.
This also breaks ABI, so we need an alternate fix for older servers,
working on the X server makes me realise why I'm a kernel hacker.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Many references to the WindowTable array already had the corresponding
screen pointer handy, which meant they usually looked like
"WindowTable[pScreen->myNum]". Adding a field to ScreenRec instead of
keeping this information in a parallel array simplifies those
expressions, and eliminates a MAXSCREENS-sized array.
Since dix uses this data, a screen private entry isn't appropriate.
xf86-video-dummy currently uses WindowTable, so it needs to be updated
to reflect this change.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Tested-by: Tiago Vignatti <tiago.vignatti@nokia.com> (i686 GNU/Linux)
Most references to the savedScreenInfo array already had the
corresponding screen pointer handy, which meant they usually looked like
"savedScreenInfo[pScreen->myNum]". Adding a field to ScreenRec instead
of keeping this information in a parallel array simplifies those
expressions, and eliminates a MAXSCREENS-sized array.
Since dix uses this data, a screen private entry isn't appropriate.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Tiago Vignatti <tiago.vignatti@nokia.com>
Tested-by: Tiago Vignatti <tiago.vignatti@nokia.com> (i686 GNU/Linux)
We just never initialised the malloced value.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Rather than always returning BadValue, associate an error status like
BadWindow with a resource type like RT_WINDOW, and return the
appropriate one for the requested type.
This patch only touches the core protocol resource types. Others still
return BadValue and need to be mapped appropriately.
dixLookupResourceByType can now return BadImplementation, if the caller
asked for a resource type that has not been allocated in the server.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Just let Dispatch() check for a noClientException, rather than making
every single dispatch procedure take care of it.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
The only remaining X-functions used in server are XNF*, the rest is converted to
plain alloc/calloc/realloc/free/strdup.
X* functions are still exported from server and x* macros are still defined in
header file, so both ABI and API are not affected by this change.
Signed-off-by: Mikhail Gusarov <dottedmag@dottedmag.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The problem fixed by this patch can be reproduced on Linux with the
following steps.
- Access NULL pointer intentionally in ProcessOtherEvent on key press.
- Instead of saving core dump to a file, write it into a pipe.
echo "|/usr/sbin/my-core-dumper" > /proc/sys/kernel/core_pattern
- Dump the core by pressing a key.
While the core is being dumped into the pipe, the smart schedule timer
will cause a pending SIGALRM. Linux kernel stops writing data to the
pipe when there are pending signals. This causes the core dump to be
truncated. On my system I'm expecting a 6 MB dump but the size will be
60 kB instead. The problem is solved if we block the SIGALRM caused by
expired smart schedule timer.
I haven't been able to reproduce this problem in the following cases.
- Save core dump to a file instead of a pipe.
- kill -SEGV `pidof Xorg`
- Press a key to dump core while gdb is attached to Xorg.
- Give option -dumbSched to Xorg.
Also note that the fix works only when NoTrapSignals has the default
value FALSE. The problem can still be reproduced if error signals
aren't trapped. In addition to pending SIGALRM, there is a similar
problem with pending SIGIO from the keyboard driver during core dump.
Signed-off-by: Rami Ylimaki <ext-rami.ylimaki@nokia.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Convert all calls of CreateNewResourceType to pass name argument
Breaks DIX ABI.
ABI versions bumped:
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Calls RegisterResourceName to record the type name for
use by X-Resource, XACE/SELinux/XTsol, and DTrace.
Signed-off-by: Alan Coopersmith <alan.coopersmith@sun.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
They were aimed towards a since abandoned approach for making radeon KMS work
on big endian machines, and Aaron Plattner pointed out that they break the
Composite extension when the X server runs in 16bpp.
Signed-off-by: Michel Dänzer <daenzer@vmware.com>
Tested-by: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
On 64-bit systems, int and pointers don't have the same size, so GCC gives
warnings about casts between int and pointer types. However, in the cases
covered by this patch, it's always a value that fits in int being stored
temporarily as a pointer and then converted back later, which is safe.
Casting through the pointer-sized integer type intptr_t convinces the
compiler that this is OK.
Signed-off-by: Jamey Sharp <jamey@minilop.net>
Signed-off-by: Daniel Stone <daniel@fooishbar.org>
The previous code was copied and in both cases incorrectly fixed
up the colormaps after resizing the visuals, this patch consolidates
the visual resize + colormaps fixups in one place. This version
also consolidates the vid allocation for the DepthPtr inside the
function.
I'm not 100% sure colormap.[ch] is the correct place for this but
visuals are mostly created in fb and I know thats not the place to
be resizing them.
Fixes fd.o bug #19470.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
include/protocol-versions.h specifies each extension version as supported by
the server and sent back on the wire to the client.
This fixes up several issues with the server potentially reporting a higher
version of the protocol if recompiled against a newer version of the
protocol.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Rémi Cardona <remi@gentoo.org>
Acked-by: Julien Cristau <jcristau@debian.org>
Otherwise, you'd still advertise the extension even if no screens
actually supported it, and the first Composite protocol request would
probably crash.
Drivers need this if they add visuals that require implicit redirection. Add a
new SDK header, compositeext.h, to contain the prototype for this function.
Otherwise it's impossible to get the COW without a white
flash on the screen, because it's on top, mapped immediately,
and unaffected by composite redirection. This makes
initial login ugly when it doesn't need to be.
dixLookupResource attempted to automatically detect whether the caller
wanted a lookup by-type or by-class, unfortunately, it guessed wrong for
RT_NONE. Instead of trying to make the guess better, this patch just reverts
the unification and creates separate functions for each operation.
Valgrind warned me about two other uninitialized variables, which are not
padding. Valgrind output at the end. I'm a bit unsure of what these should
be initialized to, is zero fine?
Save in a few special cases, _X_EXPORT should not be used in C source
files. Instead, it should be used in headers, and the proper C source
include that header. Some special cases are symbols that need to be
shared between modules, but not expected to be used by external drivers,
and symbols that are accessible via LoaderSymbol/dlopen.
This patch also adds conditionally some new sdk header files, depending
on extensions enabled. These files were added to match pattern for
other extensions/modules, that is, have the headers "deciding" symbol
visibility in the sdk. These headers are:
o Xext/panoramiXsrv.h, Xext/panoramiX.h
o fbpict.h (unconditionally)
o vidmodeproc.h
o mioverlay.h (unconditionally, used only by xaa)
o xfixes.h (unconditionally, symbols required by dri2)
LoaderSymbol and similar functions now don't have different prototypes,
in loaderProcs.h and xf86Module.h, so that both headers can be included,
without the need of defining IN_LOADER.
xf86NewInputDevice() device prototype readded to xf86Xinput.h, but
not exported (and with a comment about it).
When changing a window from automatic redirection to manual redirection, the
parent clip list needs to be recomputed; the easy way to get that computed
right is to unmap/map the window, just as when redirecting the window the
first time.
Thanks to Owen Taylor for helping diagnose this.
Signed-off-by: Keith Packard <keithp@keithp.com>
- Redo damage naming for more consistency.
- Call post submission functions only where appropriate.
- EXA can now live without it's odd damage workarounds.
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
The composite overlay window code had several misunderstandings of the
workings of the X server, in particular error handling paths would often
double-free objects. Clean all of this up by using resource destruction as
the sole mechanism for freeing resource-based objects.
- 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().
These hints allow an acceleration architecture to optimize allocation of certain
types of pixmaps, such as pixmaps that will serve as backing pixmaps for
redirected windows.