Using calloc() instead of malloc() as preventive measure, so there
never can be any hidden bugs or leaks due uninitialized memory.
The extra cost of using this compiler intrinsic should be practically
impossible to measure - in many cases a good compiler can even deduce
if certain areas really don't need to be zero'd (because they're written
to right after allocation) and create more efficient machine code.
The code pathes in question are pretty cold anyways, so it's probably
not worth even thinking about potential extra runtime costs.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It's always enabled for very long time now (at least since meson transition),
there doesn't seem to be any need to ever disable it again. So we can reduce
code complexity by removing all the ifdef's.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new PostCreateScreenResources screen hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new pixmap destroy notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new screen close notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window position notify hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons,
so use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This wrapped CloseScreen function doesn't do anything actually useful,
so no need to keep it around any longer. It used to do a free() on the
private data (which had been wrong in the first place) but this had
been removed and so the whole function became useless, it had been
forgotten to be swept away.
Fixes: 469d5bf8b7
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Right now, we're assuming that even when deep nesting involved, the proc
vector is always set to a valid function. One the one hand it requires
extra dummy procs in some cases, OTOH it's making upcoming refactoring
of the code flow unnecessarily complex.
The big plot (of subsequent commits) is splitting out the extension's
(and possibly subsystem's) special logic out of the wrapping chain and
let them be executed independently from the DDX/drivers - when applicable
even only when the pixmap is really destroyed (not just unref'ed).
(At some later point, it might even become be actually a valid situation
that DestroyPixmap vector really being NULL.)
See: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1754
See: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1755
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1709>
The symbol controls whether to include dix-config.h, and it's always set,
thus we don't need it (and dozens of ifdef's) anymore.
This commit only removes them from our own source files, where we can
guarantee that dix-config.h is present - leaving the (potentially exported)
headers untouched.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This function isn't used by any driver and doesn't seem to be useful for them,
thus move it out of the public module API, in order to tidy it up a bit.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1366>
public server module API headers shouldn't be clobbered with non-exported
definitions, so move them out to private header file.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1293>
Public module API headers don't need / shouldn't to contain anything that
isn't part of the API (non-exported functions, etc).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1287>
This breaks the xf86-input-synaptics driver:
synaptics.c: In function 'clickpad_guess_clickfingers':
synaptics.c:2638:5: error: implicit declaration of function 'BUG_RETURN_VAL' [-Werror=implicit-function-declaration]
2638 | BUG_RETURN_VAL(hw->num_mt_mask > sizeof(close_point) * 8, 0);
This reverts commit 442aec2219.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1316>
Yet another step of uncluttering includes: move out the BUG_* macros
into a separate header, which then is included as-needed.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This updates rootless to treat pixmaps consistently with COMPOSITE,
using the screen_x and screen_y values rather than doing hacky math.
This will allow for proper bounds checking on a given PixmapRec.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
This should no longer be necessary since we only support implementations
that handle preserving the bits across resize. We can use
RootlessNoCopyWindow instead.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
This should no longer be necessary since we only support implementations that handle preserving the bits across resize
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
I don't see a reason why we would want to preserve pixels that are going to
not be visible anyways. The rootless implementation already handles
preserving the relevant bits for us.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
If none of the four corners is fixed, we can use RL_GRAVITY_NORTH_WEST weighting
for the operation to let the implementation presetve the window bits for us.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
The implementation owns the pointer during RootlessStopDrawing and
RootlessStartDrawing and is free to (does) change it. Rootless
cannot assume ownership of this memory region. This is possibly
the cause of some hard to diagnose crashes in XQuartz over the
years.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
In both cases we check for width > 0 just above, and the variable is not
modified between the checks, so the condition is always true.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
Most (but not all) of these were found by using
codespell --builtin clear,rare,usage,informal,code,names
but not everything reported by that was fixed.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Slightly simplifies the callers since they don't need to check for
non-NULL anymore.
I do extremely hate the workarounds here to suppress misprite taking the
cursor down though. Surely there's a better way.
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
With a 32-bit build, putting the initialized field at the end of the
struct bumped the struct size from 20 bytes to 24, changing the layout
of other structs embedding struct _SyncObject. While this would be
acceptable on master, it caused crashes with 1.20.
Making the initialized field a char and putting it in the hole before
the beingDestroyed field restores the 32-bit ABI as well.
Fixes https://gitlab.freedesktop.org/xorg/xserver/issues/892
Reviewed-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Alex Goins <agoins@nvidia.com>
The initialized field was added in:
commit 82f01ad786
Author: Alex Goins <agoins@nvidia.com>
Date: Wed Apr 10 13:48:02 2019 -0500
xsync: Add resource inside of SyncCreate, export SyncCreate
But it added this field not at the end of SyncObject. It may not have
been _usefully_ possible to create those from another extension prior to
that commit, but that's still an ABI-incompatible change.
When using the Meson build system, miext/sync would be build only for
dri3.
As a result, when building with Meson without DRI3 enabled, Xwayland
would fail to link because `miSyncShmScreenInit()` is nowhere to be
found.
Make sure to build miext/sync for either DRI3 or Xwayland.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
As shown by DRI3 adding the SyncCreateFenceFromFD() function, extensions may
want to create a fence, then initialize it in their own way. This currently
can't be done without adding a function directly to Xext/sync.c due to the fact
that the RTFence resource type is private and there is no external interface to
add to it.
To facilitate other X extensions creating fences and initializing them, this
change exports SyncCreate() and adds the resource directly within it. Callers no
longer need to call AddResource() after SyncCreate(), they only need to
initialize the SyncObject.
To prevent FreeFence() and FreeCounter() from segfaulting if the call to
AddResource() fails before the sync object is initialized, this adds a new
'initialized' parameter to SyncObject that, when FALSE, causes FreeFence() and
FreeCounter() to skip de-initialization and simply free the object.
Initialization after adding the resource shouldn't otherwise be a problem due to
the single-threaded nature of X.
Signed-off-by: Alex Goins <agoins@nvidia.com>
Reviewed-by: James Jones <jajones@nvidia.com>
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Enrico Weigelt, metux IT consult
Aki Sakurai
Peter Hutterer
Jeremy Huddleston Sequoia
Povilas Kanapickas
Jan Beich
Alan Coopersmith
Adam Jackson
Michel Dänzer
Olivier Fourdan
Jon Turney
Alex Goins