Right now, extension specific actions on window positioning are implemented
by wrapping the ScreenRec's PositionWindow() proc pointer: the extensions are
storing the original pointer in their private data and putting in their own one.
On each call, their proc restores the original one, calls it, and switches back
again. When multiple extensions doing so, they're forming a kind of daisy chain.
(the same is done for lots of other procs)
While that approach is looking nice and elegant on the drawing board, it's
complicated, dangerous like a chainsaw and makes debugging hard, leading to
pretty blurred API borders.
This commit introduces a simple approach for letting extension hook into the
window positioning path safely, w/o having to care much about side effects
with the call chain. Extensions now can simply register their hook proc
(and an opaque pointer) and get called back - w/o ever having to mess with
the ScreenRec's internal structures. These hooks are called before the original
vector (usually handled by DDX/screen driver directly) is called.
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>
Direct calls to ScreenRec->DestroyPixmap() blocks cleaning up the wrapping
jungle, so use the proper dix function instead.
See: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1754
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
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>
We alread have several of these calls, that aren't interested in result value,
explicitly casting to void. Fixing this up for the remaining ones.
This is helpful for the human reader as well as quality analysis tools.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1648>
This has been nothing but an alias for two decades now (somewhere in R6.6),
so there doesn't seem to be any practical need for this indirection.
The macro still needs to remain, as long as (external) drivers still using it.
Fixes: ded6147bfb
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1529>
With aa3f5023e3, pScreen->devPrivate now is
initialized only once, which uncovered a silent bug in xnestOpenScreen:
It's NULL'ing the pScreen->devPrivate pointer which already had been
initialized by previous miScreenDevPrivateInit() call.
Fixes: aa3f5023e3
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1495>
Since we already had to rename some of them, in order to fix name clashes
on win32, it's now time to rename all the remaining ones.
The old ones are still present as define's to the new ones, just for
backwards compatibility.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1355>
This allows pScreen->{width,height} to be changed to smaller values
after miScreenInit() is called but before pScreen is further set up
/ used by dix, so that the screen size can be fit to the mode of
choice even when it does not have the maximum width and/or height
among its peers.
XGetImage() for one will fail once the screen is change back to a
bigger size with xrandr, which prevents e.g. x11vnc to work on the
server.
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/854>
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/577
This patch replaces the instances of trunc in miPointerSetPosition by
floor, thereby removing the incorrect behaviour with subpixel pointer
locations between -1 and 0.
This is the relevant code fragment:
/* In the event we actually change screen or we get confined, we just
* drop the float component on the floor
* FIXME: only drop remainder for ConstrainCursorHarder, not for screen
* crossings */
if (x != trunc(*screenx))
*screenx = x;
if (y != trunc(*screeny))
*screeny = y;
The behaviour of this code does not match its comment for subpixel
coordinates between -1 and 0. For example, if *screenx is -0.5, the
preceding code would (correctly) clamp x to 0, but this would not be
detected by this condition, since 0 == trunc(-0.5), leaving *screenx
at -0.5, out of bounds.
This causes undesirable behaviour in GTK3 code using xi2, where negative
subpixel coordinates like this would (to all appearances randomly)
remove the focus from windows aligned with the zero boundary when the
mouse hits the left or top screen boundaries.
The other occurences of trunc in miPointerSetPosition have a more subtle
effect which would prevent proper clamping if there is a pointer limit
at a negative integer rather than at 0. This patch changes these to
floor for consistency.
Signed-off-by: Willem Jan Palenstijn <wjp@usecode.org>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1451>
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>
PointerWindows[] keeps a reference to the last window our sprite
entered - changes are usually handled by CheckMotion().
If we switch between screens via XWarpPointer our
dev->spriteInfo->sprite->win is set to the new screen's root window.
If there's another window at the cursor location CheckMotion() will
trigger the right enter/leave events later. If there is not, it skips
that process and we never trigger LeaveWindow() - PointerWindows[] for
the device still refers to the previous window.
If that window is destroyed we have a dangling reference that will
eventually cause a use-after-free bug when checking the window hierarchy
later.
To trigger this, we require:
- two protocol screens
- XWarpPointer to the other screen's root window
- XDestroyWindow before entering any other window
This is a niche bug so we hack around it by making sure we reset the
PointerWindows[] entry so we cannot have a dangling pointer. This
doesn't handle Enter/Leave events correctly but the previous code didn't
either.
CVE-2023-5380, ZDI-CAN-21608
This vulnerability was discovered by:
Sri working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Adam Jackson <ajax@redhat.com>
To correctly render a window making use of SHAPE, a compositor
must query the shape rectangles. This may not be a desirable
feature for a Wayland compositor. Allow SHAPE to be turned off at
runtime, so that the compositor can opt-out.
Signed-off-by: Simon Ser <contact@emersion.fr>
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>
Not all extensions can be enabled or disabled at runtime, list the
extensions which can from the help message rather than on error only.
v2:
* Print the header message in the ListStaticExtensions() (Peter
Hutterer)
* Do not export ListStaticExtensions() as Xserver API
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
When enabling or disabling an extension which is not known to the
Xserver, it will log an error message and list the extensions it knows
about.
That clutters the logs when the Xserver is Xwayland spawned by the
Wayland compositor who doesn't actually know the list of extensions
enabled at build time in the Xserver.
Considering that disabling a non-existing extension is a no-op anyway,
list all the extensions available only when attempting to enable an
extension which the Xserver doesn't know about.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Enrico Weigelt, metux IT consult
Tom Yan
Willem Jan Palenstijn
Peter Hutterer
Michel Dänzer
Simon Ser
Alan Coopersmith
Jeremy Huddleston Sequoia
Povilas Kanapickas
Jan Beich
Matthieu Herrb
Olivier Fourdan