Even though shouldn't be practically hit, better have some asserts,
giving us an idea of the point of cause, instead of segfaulting,
just in case.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Protect against `inputMasks` could be NULL.
| ../Xi/exevents.c: In function ‘DeviceEventSuppressForWindow’:
| ../Xi/exevents.c:3246:32: warning: dereference of NULL ‘inputMasks’ [CWE-476] [-Wanalyzer-null-dereference]
| 3246 | FreeResource(inputMasks->inputClients->resource, X11_RESTYPE_NONE);
| | ~~~~~~~~~~^~~~~~~~~~~~~~
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers, so no need to keep it exported.
Also spending it for a better fitter name.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Not used by any drivers, so no need to keep it exported.
Also spending it for a better fitter name.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The include has become empty now. Not used by any external drivers,
so it can be dropped now.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
* unexport functions from dixgrab.h, that aren't used by any driver/module.
* add paremeter names to prototypes
* add doxygen-style documentation for all the prototypes
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>
The xnfreallocarray was added along (and just as an alias to) XNFreallocarray
back a decade ago. It's just used in a few places and it's only saves us from
passing the first parameter (NULL), so the actual benefit isn't really huge.
No (known) driver is using it, so the macro can be dropped entirely.
Fixes: ae75d50395
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1529>
he generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
The generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
The generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
The generic XaceHook() call isn't typesafe (und unnecessarily slow).
Better add an explicit function, just like we already have for others.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1556>
Windows' native headers using some our RT_* define's names for other things.
Since the naming isn't very nice anyways, introducing some new ones
(X11_RESTYPE_NONE, X11_RESTYPE_FONT, X11_RESTYPE_CURSOR) and define the old
ones as an alias to them, in case some out-of-tree code still uses them.
With thins change, we don't need to be so extremely careful about include
ordering and have explicit #undef's in order to prevent name clashes on
Win32 targets.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1355>
This header isn't installed, so no external modules could use the
functions declared there. Thus we can unexport it all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1358>
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>
There's a racy sequence where a master device may copy the button class
from the slave, without ever initializing numButtons. This leads to a
device with zero buttons but a button class which is invalid.
Let's copy the numButtons value from the source - by definition if we
don't have a button class yet we do not have any other slave devices
with more than this number of buttons anyway.
CVE-2024-0229, ZDI-CAN-22678
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
button->xkb_acts is supposed to be an array sufficiently large for all
our buttons, not just a single XkbActions struct. Allocating
insufficient memory here means when we memcpy() later in
XkbSetDeviceInfo we write into memory that wasn't ours to begin with,
leading to the usual security ooopsiedaisies.
CVE-2023-6377, ZDI-CAN-22412, ZDI-CAN-22413
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
CVE-2023-0494, ZDI-CAN-19596
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
When processing events we operate on InternalEvent pointers. They may
actually refer to a an instance of DeviceEvent, GestureEvent or any
other event that comprises the InternalEvent union. This works well in
practice because we always look into event type before doing anything,
except in the case of copying the event.
*dst_event = *src_event would copy whole InternalEvent event and would
cause out of bounds read in case the pointed to event was not
InternalEvent but e.g. DeviceEvent.
This regression has been introduced in
23a8b62d34.
Fixes https://gitlab.freedesktop.org/xorg/xserver/-/issues/1261
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
This fixes a crash when a DeviceEvent struct converted to
InteralEvent was beeing copied as InternalEvent (and thus
causing out of bounds reads) in ActivateGrabNoDelivery()
in events.c: 3876 *grabinfo->sync.event = *real_event;
Possible fix for https://gitlab.freedesktop.org/xorg/xserver/-/issues/1253
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Delivery of emulated events usually happens only to the owning client.
If there are grabs, only the grabbing client may receive these events.
This logic does not work during the touch event replay in
DeactivatePointerGrab(), as the previous grab is no longer in the
listener queue of the touch, so the next owner gets whole emulated event
sequence. This may trigger implicit grabs. After replay,
DeactivatePointerGrab() will update the global grab without regard to
this new implicit grab, which leads to issues down the line.
This change is effectively the same as 35e5a76cc1 except that the change
is limited to only emulated pointer events. Otherwise, in the case of a
device grab we end up not sending any touch events to clients that
selected XI_TouchOwnership event and should get touch events before they
get ownership of touch sequence.
Fixes#7https://bugs.freedesktop.org/show_bug.cgi?id=96536
Pointer-emulated touch events should only be delivered to the client
that owns the sequence even if it's a core client that became the
effective owner of the sequency by selecting for pointer press and
movement.
Currently the emulated events are delivered like this already (see
TouchResourceIsOwner() check in DeliverEmulatedMotionEvent()), except in
the case of TouchEnd, in which case the generated motion event is still
delivered to some client that's not necessarily the owner of the touch
sequence.
We already know whether a touch sequence that is about to emulate a
pointer event has an owner, we just need to check that. This further
allows to simplify DeliverEmulatedMotionEvent() as it won't ever be
called for non-owned touch events.
https://bugs.freedesktop.org/show_bug.cgi?id=60394
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>
When Retrieving touch delivery data we need to check if we have an active
grab on such device, and in that case use it to delivery events.
If we don't do this, when rejecting the touch events in DeactivatePointerGrab,
we will end-up in creating an implicit grab that will change the device
deviceGrab's state, causing a recursion during TouchEndTouch.
Fixes#7https://bugs.freedesktop.org/show_bug.cgi?id=96536
Commits 816015648f and
fee0827a9a made it so that
wl_keyboard::enter doesn't result in X clients getting KeyPress events
while still updating our internal xkb state to be in sync with the
host compositor.
wl_keyboard::leave needs to be handled in the same way as its
semantics from an X client POV should be the same as an X grab getting
triggered, i.e. X clients shouldn't get KeyRelease events for keys
that are still down at that point.
This patch uses LeaveNotify for these events on wl_keyboard::leave and
changes the current use of KeymapNotify to EnterNotify instead just to
keep some symmetry between both cases.
On ProcessDeviceEvent() we still need to deactivate X grabs if needed
for KeyReleases.
Signed-off-by: Rui Matos <tiagomatos@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This removes all of the SIGIO handling support used for input
throughout the X server, preparing the way for using threads for input
handling instead.
Places calling OsBlockSIGIO and OsReleaseSIGIO are marked with calls
to stub functions input_lock/input_unlock so that we don't lose this
information.
xfree86 SIGIO support is reworked to use internal versions of
OsBlockSIGIO and OsReleaseSIGIO.
v2: Don't change locking order (Peter Hutterer)
v3: Comment weird && FALSE in xf86Helper.c
Leave errno save/restore in xf86ReadInput
Squash with stub adding patch (Peter Hutterer)
v4: Leave UseSIGIO config parameter so that
existing config files don't break (Peter Hutterer)
v5: Split a couple of independent patch bits out
of kinput.c (Peter Hutterer)
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The touchpoint knows whether it should be emulating or not and we have a check
for that later. Check for this before we generate the event and try to deliver
it, lest we trigger a bug warning.
https://bugzilla.redhat.com/show_bug.cgi?id=1282252
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Add a new event source type for keypress events synthesised from focus
notifications (e.g. KeymapNotify from the parent server, when running
nested). This is used to keep the keys-down array in sync with the host
server's, without sending actual keypress events to clients.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The client window can be closed in the middle of a touch sequence,
e.g. Qt 4 closes popup windows on MousePress and Qt 5.5 will do it
on TouchBegin. In this case the state of mouse buttons will not be
updated on TouchEnd because ProcessTouchEvent() calls UpdateDeviceState()
only when the event has been sent to the client. It results in a
stuck left mouse button.
This patch leads to calling UpdateDeviceState() in case the client
can't be found.
Signed-off-by: Alexander Volkov <a.volkov@rusbitech.ru>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
While it's documented in the XACE spec, the XACE_KEY_AVAIL hook is
currently never actually invoked by the xserver.
This hook was added in 13c6713c82 (25 Aug 2006), but as the keyboard
processing was moved into XKB, the hook was forgotten and silently
dropped. The code calling this hook was removed by 7af53799c (4 Jan
2009), but it was probably already unused before that.
This patch re-adds support for this hook. The "count" hook parameter is
unused.
Signed-off-by: Andrew Eikum <aeikum@codeweavers.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Enrico Weigelt, metux IT consult
Peter Hutterer
Povilas Kanapickas
Matthieu Herrb
Alan Coopersmith
Adam Jackson
Marco Trevisan (Treviño)
Rui Matos
Keith Packard
Daniel Stone
Alexander Volkov
Andrew Eikum