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>
The mode (CoordModeOrigin or CoordModePrevious) was not taken into
account when computing the box. The result was a bad drawing of
points in some situations (on my hardware/software configuration,
calling XDrawString followed by XDrawPoints in the mode
CoordModePrevious).
Signed-off-by: Cedric Roux <sed@free.fr>
Signed-off-by: Eric Anholt <eric@anholt.net>
Install missing headers to the SDK directory to allow external modules
to properly build against the SDK. After this commit, the list of files
installed in the SDK include directory is the same as the list of files
installed by the autotools-based build.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The extension was using the name CARD64 to represent 64-bit values,
with a #define from CARD64 to XSyncValue, a struct with a pair of
32-bit values representing a signed 64-bit value. This interfered
with protocol headers using CARD64 to try to actually store a
uint64_t. Now that stdint.h exists, let's just use that here,
instead.
v2: Fix alarm delta changes.
v3: Do the potentially overflowing math as uint and convert to int
afterward, out of C spec paranoia.
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
This is a work in progress that builds Xvfb, Xephyr, Xwayland, Xnest,
and Xdmx so far. The outline of Xquartz/Xwin support is in tree, but
hasn't been built yet. The unit tests are also not done.
The intent is to build this as a complete replacement for the
autotools system, then eventually replace autotools. meson is faster
to generate the build, faster to run the bulid, shorter to write the
build files in, and less error-prone than autotools.
v2: Fix indentation nits, move version declaration to project(), use
existing meson_options for version-config.h's vendor name/web.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
None of this is actually wired up to anything, so we can also remove the
devPrivates from the DamageRec. The DamageExtRec is what would need
devPrivates for selinux labeling, in principle.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
The lower layers also do this, but no damage may be reported there,
since we unwrap before calling down.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99220
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The commit message makes the assertion that the code below damage is not
allowed to change whether there's a damage monitor for the drawable.
That turns out not to be the case! exa's mixed code, at least, will
create and destroy a damage in PrepareAccess. The destroy path can then
be catastrophic, as damageRegionProcessPending will attempt to
RegionEmpty memory from the middle of a freed block.
I'd wanted that invariant for performance, but faster isn't worth
broken, so revert it. I think what exa's doing is reasonable, so the
better way to improve performance for the unmonitored case is to either
revisit dynamically wrapping into the GC, or inline damage into dix.
This reverts commit 4e124203f2.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1389886
Signed-off-by: Adam Jackson <ajax@redhat.com>
shadowDamage is just obfuscation. The other two macros won't work
outside shadow.c since the private key is in fact static there (meaning
the extern decl is a lie).
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.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
Cedric Roux
Thierry Reding
Eric Anholt
Michel Dänzer