These functions aren't supposed to be used by drivers, so move them
out of the public API.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
PANORAMIX was the original working title of the extension, before it became
official standard. Just nobody cared about fixing the symbols to the official
naming.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Both xlib as well as the Xserver use the same identifier "GC" for
different types. While on xlib it's just the numerical ID of a GC,
the xserver defines a struct for it by the same name. This is this
ugly and needs ridiculous hacks for Xserver code that needs xlib.
Easy to solve by just renaming the GC typedef to GCRec (consistent
with how we're naming other structs) and replacing GC* by GCPtr.
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>
It's not good having the public server api headers clobbered with private
definitions, so cleaning them up.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Since most of the extension init logic (and on/off switches for them)
is driven from miext, this seems the appropriate place for the header.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Several sources including it without need. For consistency, those who still
need someting from there should include exitinit_priv.h (which also pulls
in extinit.h)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Now that Xnest is taking care of disbling unsupported extensions itself,
no more need for the special hack in here. Including xnest-config.h also
isn't needed anymore.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
With removal of Xwin's NATIVEGDI (back a decade ago), the last caller is
gone, and it also doesn't seem to be called by any driver.
Fixes: 8465ee788f
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
With removal of Xwin's NATIVEGDI (back a decade ago), the last caller is
gone, and it also doesn't seem to be called by any driver.
Fixes: 8465ee788f
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
With removal of Xwin's NATIVEGDI (back a decade ago), the last caller is
gone, and it also doesn't seem to be called by any driver.
Fixes: 8465ee788f
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
With removal of Xwin's NATIVEGDI (back a decade ago), the last caller is
gone, and it also doesn't seem to be called by any driver.
Fixes: 8465ee788f
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