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>
These aren't used by any drivers/modules, just DDX'es, so no need to export.
Note: tigervnc does use it, but it has it's own DDX, therefore directly
linked in, just like the in-tree DDX'es which doesn't need exporting.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1349>
* this symbol is a server configuration flag (can be passed via cmdline)
for limiting the max size of big-requests. there shouldn't be any need
to use it outside the core X server (in server modules like drivers
or external extension) - therefore unexport it
* in order to reduce namespace pollution of public (server module API)
headers, create a new internal header for those tings (more to come)
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1275>
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>
The workQueue pointer is currently declared extern, so that WaitForSomething()
can check wether we've got something in the queue and call ProcessWorkQueue()
then.
But that's trivial to simplify: just let ProcessWorkQueue() return early if
workQueue == NULL. Gives us a better isolation of internal stuff as well as
ProcessWorkQueue() protecting itself from possible segfault.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Part-of: <https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1310>
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>
CreateGC() allocates a new GC and then checks the resource access rights
with XaceHook().
If the call to XaceHook() fails (i.e. GC creation is not granted to the
client), CreateGC() exits early and calls FreeGC() to avoid leaking the
newly allocated GC.
If that happens, the screen's own CreateGC() has not yet been invoked,
and as a result the GC functions (GCfuncs) have not been set yet.
FreeGC() will invoke the funcs->DestroyClip() and the funcs->DestroyGC()
functions, but since those haven't been set, the Xserver will segfault
trying to call a NULL function.
To prevent that issue, make sure the GC's functions are initialized
prior to call them in FreeGC().
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1625
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Disabling a master device floats all slave devices but we didn't do this
to already-disabled slave devices. As a result those devices kept their
reference to the master device resulting in access to already freed
memory if the master device was removed before the corresponding slave
device.
And to match this behavior, also forcibly reset that pointer during
CloseDownDevices().
Related to CVE-2024-21886, ZDI-CAN-22840
The `DisableDevice()` function is called whenever an enabled device
is disabled and it moves the device from the `inputInfo.devices` linked
list to the `inputInfo.off_devices` linked list.
However, its link/unlink operation has an issue during the recursive
call to `DisableDevice()` due to the `prev` pointer pointing to a
removed device.
This issue leads to a length mismatch between the total number of
devices and the number of device in the list, leading to a heap
overflow and, possibly, to local privilege escalation.
Simplify the code that checked whether the device passed to
`DisableDevice()` was in `inputInfo.devices` or not and find the
previous device after the recursion.
CVE-2024-21886, ZDI-CAN-22840
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
The previous code only made sense if one considers buttons and keys to
be mutually exclusive on a device. That is not necessarily true, causing
a number of issues.
This function allocates and fills in the number of xEvents we need to
send the device state down the wire. This is split across multiple
32-byte devices including one deviceStateNotify event and optional
deviceKeyStateNotify, deviceButtonStateNotify and (possibly multiple)
deviceValuator events.
The previous behavior would instead compose a sequence
of [state, buttonstate, state, keystate, valuator...]. This is not
protocol correct, and on top of that made the code extremely convoluted.
Fix this by streamlining: add both button and key into the deviceStateNotify
and then append the key state and button state, followed by the
valuators. Finally, the deviceValuator events contain up to 6 valuators
per event but we only ever sent through 3 at a time. Let's double that
troughput.
CVE-2024-0229, ZDI-CAN-22678
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
If a device has both a button class and a key class and numButtons is
zero, we can get an OOB write due to event under-allocation.
This function seems to assume a device has either keys or buttons, not
both. It has two virtually identical code paths, both of which assume
they're applying to the first event in the sequence.
A device with both a key and button class triggered a logic bug - only
one xEvent was allocated but the deviceStateNotify pointer was pushed on
once per type. So effectively this logic code:
int count = 1;
if (button && nbuttons > 32) count++;
if (key && nbuttons > 0) count++;
if (key && nkeys > 32) count++; // this is basically always true
// count is at 2 for our keys + zero button device
ev = alloc(count * sizeof(xEvent));
FixDeviceStateNotify(ev);
if (button)
FixDeviceStateNotify(ev++);
if (key)
FixDeviceStateNotify(ev++); // santa drops into the wrong chimney here
If the device has more than 3 valuators, the OOB is pushed back - we're
off by one so it will happen when the last deviceValuator event is
written instead.
Fix this by allocating the maximum number of events we may allocate.
Note that the current behavior is not protocol-correct anyway, this
patch fixes only the allocation issue.
Note that this issue does not trigger if the device has at least one
button. While the server does not prevent a button class with zero
buttons, it is very unlikely.
CVE-2024-0229, ZDI-CAN-22678
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Both DeviceFocusEvent and the XIQueryPointer reply contain a bit for
each logical button currently down. Since buttons can be arbitrarily mapped
to anything up to 255 make sure we have enough bits for the maximum mapping.
CVE-2023-6816, ZDI-CAN-22664, ZDI-CAN-22665
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
XTest requests lets the client specify a device ID, only if none
is specified do we fall back to the XTEST special device.
As of commit
aa4074251 input: Add new hook DeviceSendEventsProc for XTEST
regular devices are no longer able to send XTest events because they
have no sendEventsProc set.
This caused issue #1574 and the crash was fixed with commit
e820030de xtest: Check whether there is a sendEventsProc to call
but we still cannot send XTest events through a specific device.
Fix this by defaulting every device to the XTest send function and
punting it to the DDX (i.e. Xwayland) to override the devices as
necessary.
Fixes e820030de2
Fixes aa4074251f
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
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>
This is to make sure the hardware gets the device states regardless
whether the internal state has changed or not, to overcome situations
that device LEDs are out of sync e.g. switching between VTs.
Signed-off-by: Yao Wei (魏銘廷) <yao.wei@canonical.com>
The increment sign wasn't taking into account when checking if the next
value is past our current value. The result was that for negative
increments, we kept looping indefinitely, locking up the server.
Easiest to reproduce with the evdev driver which has a negative
increment on the y axis.
Fixes 0a22502c34
dix: switch scroll button emulation to multiples of increment
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The current algorithm triggers a bug in Xwayland when two devices have
different granularity of scrolling. In Xwayland, the scroll increment is
1 and all physical devices scroll through the same (x)wayland pointer
device.
This may cause events to get lost when changing devices:
- mouse scrolls by full increment, current value is 1.0
last scroll button was sent for valuator value 0.0,
delta is 1.0 and we emulate a button event.
- touchpad scrolls by partial increment, current value is 1.3
last scroll button was sent for valuator value 1.0, delta is 0.3
and no button event is emulated
- mouse scrolls by full increment, current value is -0.7,
last scroll button was sent for valuator value 1.0, delta is -0.7
and no button event is emulated
Thus the wheel event appears to get lost. Xwayland cannot reliably
detect this case because we don't see the physical devices.
We can work around this by instead emulating buttons whenever we cross
a multiple of increment. However, this has a drawback:
high-resolution scroll devices can now trigger a button event storm by
jittering across the multiple of increment. e.g. in the example above
the touchpad moving from 1.3 to 1.0 would cause a click, despite this
being a third of an increment.
Fixes#1339
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
storeLastValuators() takes the index in the mask for the x and y axis.
Completely pointless because any device that doesn't have x/y on 0 and
1, respectively, is going to break in fun ways anyway. And we only have
two callers two this function, both of which hardcode 0 and 1.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The code in AttachDevice() may free the dev->spriteInfo->sprite under
some circumstances and later call GetCurrentRootWindow() which uses
the same dev->spriteInfo->sprite.
While it seems unlikely that this is actually an issue, considering the
cases where one or the other get called, it still makes the code look
suspicious.
Make sure to clear set dev->spriteInfo->sprite to NULL immediately
after it's freed to avoid any confusion, even if only to clarify the
code.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1436
The event might be a DeviceEvent allocated on the stack, in
AccessXKeyboardEvent for instance. Fixes out-of-bounds read.
Signed-off-by: Mike Gorse <mgorse@suse.com>
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>
The X server swapping code is a huge attack surface, much of this code
is untested and prone to security issues. The use-case of byte-swapped
clients is very niche, so let's disable this by default and allow it
only when the respective config option or commandline flag is given.
For Xorg, this adds the ServerFlag "AllowByteSwappedClients" "on".
For all DDX, this adds the commandline options +byteswappedclients and
-byteswappedclients to enable or disable, respectively.
Fixes#1201https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1029
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The minimal performance wins we gain by recycling pixmaps at this layer are
not worth the code complexity nor the interference with memory analysis
tools like malloc history, ASan, etc.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
PixmapDirtyCopyArea() is about to be used outside of pixmap.c, so fix up
its interface by specifying the dirty area directly rather than passing a
`PixmapDirtyUpdatePtr`. This makes it easier to use outside of pixmap.c, as
the caller doesn't need to create a bulky PixmapDirtyUpdateRec to use this
function.
Signed-off-by: Sultan Alsawaf <sultan@kerneltoast.com>
This fixes an OOB read and the resulting information disclosure.
Length calculation for the request was clipped to a 32-bit integer. With
the correct stuff->num_items value the expected request size was
truncated, passing the REQUEST_FIXED_SIZE check.
The server then proceeded with reading at least stuff->num_items bytes
(depending on stuff->format) from the request and stuffing whatever it
finds into the property. In the process it would also allocate at least
stuff->num_items bytes, i.e. 4GB.
The same bug exists in ProcChangeProperty and ProcXChangeDeviceProperty,
so let's fix that too.
CVE-2022-46344, ZDI-CAN 19405
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>
Acked-by: Olivier Fourdan <ofourdan@redhat.com>
Despite e957a2e5dd ("dix: Add hybrid full-size/empty-clip mode to
SetRootClip"), I was still seeing all X11 client windows flashing when
the root window size changes with rootless Xwayland (e.g. due to
hotplugging a monitor).
Skipping this code for ROOT_CLIP_INPUT_ONLY fixes the issue for me.
Most of these came from a mass bcopy() -> memmove() substitution in 1993
with a commit comment of "Ansification (changed bfuncs -> mfuncs)"
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Commit c7311654 cached the value of ResourceClientBits(), but that value
depends on the `MaxClients` value set either from the command line or
from the configuration file.
For the latter, a call to ResourceClientBits() is issued before the
configuration file is read, meaning that the cached value is from the
default, not from the maximum number of clients set in the configuration
file.
That obviously causes all sort of issues, including memory corruption
and crashes of the Xserver when reaching the default limit value.
To avoid that issue, also keep the LimitClient value, and recompute the
ilog2() value if that changes, as on startup when the value is set from
the the xorg.conf ServerFlags section.
v2: Drop the `cache == 0` test
Rename cache vars
Fixes: c7311654 - dix: cache ResourceClientBits() value
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1310
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
GTK3 menu widget creates a selection for touch and other events and
after receiving touch events creates an async grab that excludes touch
events. Unfortunately it relies on X server not sending the touch end
event in order to function properly. Sending touch end event will cause
it to think that the initiating touch ended and when it actually ends,
the ButtonRelease event will make it think that the menu should be
closed. As a result, the menu will be open only for the duration of the
touch making it useless.
This commit reverts f682e0563f.
Fixes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1255
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
This fixes access to freed heap memory via dev->master. E.g. when
running BarrierNotify.ReceivesNotifyEvents/7 test from
xorg-integration-tests:
==24736==ERROR: AddressSanitizer: heap-use-after-free on address
0x619000065020 at pc 0x55c450e2b9cf bp 0x7fffc532fd20 sp 0x7fffc532fd10
READ of size 4 at 0x619000065020 thread T0
#0 0x55c450e2b9ce in GetMaster ../../../dix/devices.c:2722
#1 0x55c450e9d035 in IsFloating ../../../dix/events.c:346
#2 0x55c4513209c6 in GetDeviceUse ../../../Xi/xiquerydevice.c:525
../../../Xi/xichangehierarchy.c:95
#4 0x55c450e3455c in RemoveDevice ../../../dix/devices.c:1204
../../../hw/xfree86/common/xf86Xinput.c:1142
#6 0x55c450e17b04 in CloseDeviceList ../../../dix/devices.c:1038
#7 0x55c450e1de85 in CloseDownDevices ../../../dix/devices.c:1068
#8 0x55c450e837ef in dix_main ../../../dix/main.c:302
#9 0x55c4517a8d93 in main ../../../dix/stubmain.c:34
(/lib/x86_64-linux-gnu/libc.so.6+0x28564)
#11 0x55c450d0113d in _start (/usr/lib/xorg/Xorg+0x117713d)
0x619000065020 is located 160 bytes inside of 912-byte region
[0x619000064f80,0x619000065310)
freed by thread T0 here:
(/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10d7cf)
#1 0x55c450e19f1c in CloseDevice ../../../dix/devices.c:1014
#2 0x55c450e343a4 in RemoveDevice ../../../dix/devices.c:1186
../../../hw/xfree86/common/xf86Xinput.c:1142
#4 0x55c450e17b04 in CloseDeviceList ../../../dix/devices.c:1038
#5 0x55c450e1de85 in CloseDownDevices ../../../dix/devices.c:1068
#6 0x55c450e837ef in dix_main ../../../dix/main.c:302
#7 0x55c4517a8d93 in main ../../../dix/stubmain.c:34
(/lib/x86_64-linux-gnu/libc.so.6+0x28564)
previously allocated by thread T0 here:
(/usr/lib/x86_64-linux-gnu/libasan.so.5+0x10ddc6)
#1 0x55c450e1c57b in AddInputDevice ../../../dix/devices.c:259
#2 0x55c450e34840 in AllocDevicePair ../../../dix/devices.c:2755
#3 0x55c45130318f in add_master ../../../Xi/xichangehierarchy.c:152
../../../Xi/xichangehierarchy.c:465
#5 0x55c4512cb9f5 in ProcIDispatch ../../../Xi/extinit.c:390
#6 0x55c450e6a92b in Dispatch ../../../dix/dispatch.c:551
#7 0x55c450e834b7 in dix_main ../../../dix/main.c:272
#8 0x55c4517a8d93 in main ../../../dix/stubmain.c:34
(/lib/x86_64-linux-gnu/libc.so.6+0x28564)
The problem is caused by dev->master being not reset when disabling the
device, which then causes dangling pointer when the master device itself
is being deleted when exiting whole server.
Note that RecalculateMasterButtons() requires dev->master to be still
valid, so we can reset it only at the end of function.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
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>
Fix the following race:
Possible data race during read of size 8 at 0xA112510 by thread #6
Locks held: 1, at address 0x366B40
at 0x14C8B9: GetMaster (devices.c:2691)
by 0x15CFC5: IsFloating (events.c:346)
by 0x2B9554: miPointerGetScreen (mipointer.c:527)
by 0x1A5136: xf86PostButtonEventM (xf86Xinput.c:1379)
by 0x1A52BD: xf86PostButtonEvent (xf86Xinput.c:1345)
by 0x485F45B: EvdevProcessEvent (in /usr/lib64/xorg/modules/input/evdev_drv.so)
by 0x485FDAC: EvdevReadInput (in /usr/lib64/xorg/modules/input/evdev_drv.so)
by 0x195427: xf86ReadInput (xf86Events.c:247)
by 0x2CC113: InputReady (inputthread.c:180)
by 0x2CE4EA: ospoll_wait (ospoll.c:657)
by 0x2CC077: InputThreadDoWork (inputthread.c:369)
by 0x484A336: mythread_wrapper (hg_intercepts.c:406)
This conflicts with a previous write of size 8 by thread #1
Locks held: none
at 0x14D2C6: AttachDevice (devices.c:2609)
by 0x15CF85: ReattachToOldMaster (events.c:1457)
by 0x1647DD: DeactivateKeyboardGrab (events.c:1700)
by 0x25D7F1: ProcXIUngrabDevice (xigrabdev.c:169)
by 0x2552AD: ProcIDispatch (extinit.c:398)
by 0x155291: Dispatch (dispatch.c:479)
by 0x158CBA: dix_main (main.c:276)
by 0x143A3D: main (stubmain.c:34)
Address 0xa112510 is 336 bytes inside a block of size 904 alloc'd
at 0x4846571: calloc (vg_replace_malloc.c:1328)
by 0x14A0B3: AddInputDevice (devices.c:260)
by 0x1A31A0: xf86ActivateDevice (xf86Xinput.c:365)
by 0x1A4549: xf86NewInputDevice (xf86Xinput.c:948)
by 0x1A4B44: NewInputDeviceRequest (xf86Xinput.c:1090)
by 0x1B81FE: device_added (udev.c:282)
by 0x1B8516: config_udev_init (udev.c:439)
by 0x1B7091: config_init (config.c:50)
by 0x197970: InitInput (xf86Init.c:814)
by 0x158C6B: dix_main (main.c:250)
by 0x143A3D: main (stubmain.c:34)
Block was alloc'd by thread #1
The steps to trigger the race are:
1. Main thread does cleanup at mipointer.c:360 setting the slave device's
miPointerPtr to null.
2. Input thread use MIPOINTER in mipointer.c and get the slave's
miPointerPtr = null.
3. Main thread updates dev->master at devices.c:2609.
4. MIPOINTER would now return the master's miPointerPtr but the input
thread already got the slave's miPointerPtr in step 2 and segfaults by
null ptr deref.
Closes: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1260
Signed-off-by: Thomas Lindroth <thomas.lindroth@gmail.com>
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>
Adding the offset between the realloc result and the old allocation to
update pointers into the new allocation is undefined behaviour: the
old pointers are no longer valid after realloc() according to the C
standard. While this works on almost all architectures and compilers,
it causes problems on architectures that track pointer bounds (e.g.
CHERI or Arm's Morello): the DevPrivateKey pointers will still have the
bounds of the previous allocation and therefore any dereference will
result in a run-time trap.
I found this due to a crash (dereferencing an invalid capability) while
trying to run `XVnc` on a CHERI-RISC-V system. With this commit I can
successfully connect to the XVnc instance running inside a QEMU with a
VNC viewer on my host.
This also changes the check whether the allocation was moved to use
uintptr_t instead of a pointer since according to the C standard:
"The value of a pointer becomes indeterminate when the object it
points to (or just past) reaches the end of its lifetime." Casting to an
integer type avoids this undefined behaviour.
Signed-off-by: Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
In some scenarios, the Wayland compositor might have more knowledge
than the X11 server and may be able to perform pointer emulation for
touch events better. Add a command-line switch to allow compositors
to turn Xwayland pointer emulation off.
Signed-off-by: Simon Ser <contact@emersion.fr>
It is copied using memcpy() and not modified so we can add const. This
fixes a -Wincompatible-pointer-types-discards-qualifiers compiler warning
that was failing a -Werror XVnc build for me.
Signed-off-by: Alex Richardson <Alexander.Richardson@cl.cam.ac.uk>
When the command line option "-terminate" is used, it could be
interesting to give it an optional grace period to let the Xserver
running for a little longer in case a new connection occurs.
This adds an optional parameter to the "-terminate" command line option
for this purpose.
v2: Use a delay in seconds instead of milliseconds
(Martin Peres <martin.peres@mupuf.org>)
v3: Clarify man page entry, ensure terminateDelay is always >= 0,
simplify TimerFree(). (Peter Hutterer <peter.hutterer@who-t.net>)
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
With Wayland compositors now being able to start Xwayland on demand, the
next logical step is to be able to stop Xwayland when there is no more
need for it.
The Xserver itself is capable of terminating itself once all X11 clients
are gone, yet in a typical full session, there are a number of X11
clients running continuously (e.g. the Xsettings daemon, IBus, etc.).
Those always-running clients will prevent the Xserver from terminating,
because the actual number of X11 clients will never drop to 0. Worse,
the X11 window manager of a Wayland compositor also counts as an X11
client, hence also preventing Xwayland from stopping.
Some compositors such as mutter use the XRes extension to query the X11
clients connected, match their PID with the actual executable name and
compare those with a list of executables that can be ignored when
deciding to kill the Xserver.
But that's not just clumsy, it is also racy, because a new X11 client
might initiate a connection the X11 server right when the compositor is
about to kill it.
To solve this issue directly at the Xserver level, this add new entries
to the XFixes extension to let the X11 clients themselves specify the
disconnect mode they expect.
Typically, those X11 daemon clients would specify the disconnect mode
XFixesClientDisconnectFlagTerminate to let the Xserver know that they
should not be accounted for when checking the remaining clients prior
to terminate.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This fixes an problem left in f682e0563f
due to an incorrect cherry-pick.
We must use old listener->listener to deliver the touch event. Otherwise
grab won't let the event through and the abovementioned commit has no
effect.
Signed-off-by: Povilas Kanapickas <povilas@radix.lt>
Trying to change the pointer control settings on a device without
PtrFeedbackPtr would be a bug and a crash in the Xserver.
Guard against that case by returning early with a BadImplementation
error, that might kill the X11 client but the Xserver would survive.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Related: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1137
This add a new flag POINTER_RAWONLY for GetPointerEvents() which does
pretty much the opposite of POINTER_NORAW.
Basically, this tells GetPointerEvents() that we only want the
DeviceChanged events and any raw events for this motion but no actual
motion events.
This is preliminary work for Xwayland to be able to use relative motion
events for raw events. Xwayland would use absolute events for raw
events, but some X11 clients (wrongly) assume raw events to be always
relative.
To allow such clients to work with Xwayland, it needs to switch to
relative raw events (if those are available from the Wayland
compositor).
However, Xwayland cannot use relative motion events for actual pointer
location because that would cause a drift over time, the pointer being
actually controlled by the Wayland compositor.
So Xwayland needs to be able to send only relative raw events, hence
this API.
Bump the ABI_XINPUT_VERSION minor version to reflect that API addition.
v2: Actually avoid sending motion events (Peter)
v3: Keep sending raw emulated events with RAWONLY (Peter)
Suggested-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Related: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1130
If a XI2 client started listening to touches due to a selection and then
creates an active async grab that does not include touch events, then it
currently won't get the touch end event which will produce inconsistent
view of the pending touches.
Note that we only need to consider touch listeners and can ignore
pointer emulation. Under XI2 if a active grab replaces a passive
implicit grab and the active grab does not include the button release
event, the client won't get it either.
Resolves warning from Oracle Parfait static analyser:
Warning: Impossible or redundant condition
Impossible or redundant condition [impossible-redundant-condition]:
Condition 'dev != NULL' of branch is determined by previous branch
at line 270 of dix/devices.c in function 'AddInputDevice'.
Condition 'dev != NULL' from this branch implies following branch is always true at line 262
Fixes: commit 493ad83323
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Avoid leaking un-initalized memory to clients by zeroing the
whole pixmap on initial allocation.
This vulnerability was discovered by:
Jan-Niklas Sohn working with Trend Micro Zero Day Initiative
Signed-off-by: Matthieu Herrb <matthieu@herrb.eu>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
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>
If a client is in the process of being closed down, then its client->osPrivate
pointer will be set to NULL by CloseDownConnection. This can cause a crash if
freeing the client's resources results in a call to AttendClient. For example,
if the client has a pending sync fence:
Thread 1 "X" received signal SIGSEGV, Segmentation fault.
AttendClient (client=0x5571c4aed9a0) at ../os/connection.c:942
(gdb) bt
#0 AttendClient (client=0x5571c4aed9a0) at ../os/connection.c:942
#1 0x00005571c3dbb865 in SyncAwaitTriggerFired (pTrigger=<optimized out>) at ../Xext/sync.c:694
#2 0x00005571c3dd5749 in miSyncDestroyFence (pFence=0x5571c5063980) at ../miext/sync/misync.c:120
#3 0x00005571c3dbbc69 in FreeFence (obj=<optimized out>, id=<optimized out>) at ../Xext/sync.c:1909
#4 0x00005571c3d7a01d in doFreeResource (res=0x5571c506e3d0, skip=skip@entry=0) at ../dix/resource.c:880
#5 0x00005571c3d7b1dc in FreeClientResources (client=0x5571c4aed9a0) at ../dix/resource.c:1146
#6 FreeClientResources (client=0x5571c4aed9a0) at ../dix/resource.c:1109
#7 0x00005571c3d5525f in CloseDownClient (client=0x5571c4aed9a0) at ../dix/dispatch.c:3473
#8 0x00005571c3d55eeb in Dispatch () at ../dix/dispatch.c:492
#9 0x00005571c3d59e96 in dix_main (argc=3, argv=0x7ffe7854bc28, envp=<optimized out>) at ../dix/main.c:276
#10 0x00007fea4837cb6b in __libc_start_main (main=0x5571c3d1d060 <main>, argc=3, argv=0x7ffe7854bc28, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe7854bc18) at ../csu/libc-start.c:308
#11 0x00005571c3d1d09a in _start () at ../Xext/sync.c:2378
(gdb) print client->osPrivate
$1 = (void *) 0x0
Since the client is about to be freed, its ignore count doesn't matter and
AttendClient can simply be a no-op. Check for client->clientGone in AttendClient
and remove similar checks from two callers that had them.
Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
This ensures that any prep work for the drawable we're about to read
from is already done before we call down to GetImage. This should be no
functional change as most of the callers with a non-trivial
SourceValidate are already wrapping GetImage and doing the equivalent
thing, but we'll be simplifying that shortly.
More importantly this ensures that if any of that prep work would
generate events - like automatic compositing flushing rendering to a
parent pixmap which then triggers damage - then it happens entirely
before we start writing the GetImage reply header.
Note that we do not do the same for GetSpans, but that's okay. The only
way to get to GetSpans is through miCopyArea or miCopyPlane - where the
callers must already call SourceValidate - or miGetImage - which this
commit now protects with SourceValidate.
Fixes: xorg/xserver#902
Reviewed-by: Michel Dänzer <mdaenzer@redhat.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>
When we set these up initially, no subsystems have allocated any
privates yet, so the storage address will be null, and memset(NULL, ...)
is undefined.
Request-handlers as registered in the requestVector array, always get
passed the clientPtr for the client which sent the request.
But the implementation of many request-handlers typically consists of
a generic handler calling implementation specific callbacks and / or
various helpers often multiple levels deep and in many cases the clientPtr
does not get passed to the callbacks / helpers.
This means that in some places where we would like to have access to the
current-client, we cannot easily access it and fixing this would require
a lot of work and often would involve ABI breakage.
This commit adds a GetCurrentClient helper which can be used as a
shortcut to get access to the clienPtr for the currently being processed
request without needing a lot of refactoring and ABI breakage.
Note using this new GetCurrentClient helper is only safe for code
which only runs from the main thread, this new variable MUST NOT be used
by code which runs from signal handlers or from the input-thread.
The specific use-case which resulted in the creation of this patch is adding
support for emulation of randr / vidmode resolution changes to Xwayland.
This emulation will not actually change the monitor resolution instead it
will scale any window with a size which exactly matches the requested
resolution to fill the entire monitor. The main use-case for this is
games which are hard-coded to render at a specific resolution and have
sofar relied on randr / vidmode to change the monitor resolution when going
fullscreen.
To make this emulation as robust as possible (e.g. avoid accidentally scaling
windows from other apps) we want to make the emulated resolution a per client
state. But e.g. the RRSetCrtc function does not take a client pointer; and is
a (used) part of the Xorg server ABI (note the problem is not just limited
to RRSetCrtc).
Reviewed-by: Olivier Fourdan <ofourdan@redhat.com>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
There is a race when reseting the XServer that causes spriteInfo to be
NULL in GetPairedDevice resulting a segfault and subsequent crash. The
problem was noticed when opening a connection, creating master devices,
destroying master devices and closing the connection during testing.
Signed-off-by: Arthur Williams <taaparthur@gmail.com>
When compiling with link time optimization, GCC thinks it's discovered
undefined behavior:
events.c: In function 'XineramaConfineCursorToWindow':
events.c:609:13: warning: iteration 2147483647 invokes undefined behavior [-Waggressive-loop-optimizations]
events.c:609:11: note: within this loop
events.c:605:49: warning: array subscript -1 is below array bounds of 'struct _Window *[16]' [-Warray-bounds]
events.c:606:31: warning: array subscript -1 is below array bounds of 'struct _Screen *[16]' [-Warray-bounds]
events.c:610:39: warning: array subscript -2 is below array bounds of 'struct _Screen *[16]' [-Warray-bounds]
events.c:617:38: warning: array subscript -2 is below array bounds of 'struct _Window *[16]' [-Warray-bounds]
events.c:619:35: warning: array subscript -2 is below array bounds of 'struct _Screen *[16]' [-Warray-bounds]
This results from
i = PanoramiXNumScreens - 1;
RegionCopy(&pSprite->Reg1, &pSprite->windows[i]->borderSize);
off_x = screenInfo.screens[i]->x;
off_y = screenInfo.screens[i]->y;
where GCC believes that PanoramiXNumScreens might be 0. Unfortunately
GCC is just smart enough to be an annoyance because this case is not
actually possible: XineramaConfineCursorToWindow() is only called when
noPanoramiXExtension is false, and if noPanoramiXExtension is false then
PanoramiXNumScreens must be >1 (see PanoramiXExtensionInit()).
So, add an assert(!noPanoramiXExtension), which to my surprise provides
GCC with information even in release builds and lets GCC understand that
the code is not doing anything that is undefined behavior.
I chose this solution instead of the proposed assert(i >= 0) because the
same pattern occurs in CheckVirtualMotion() but is inside an
'if (!noPanoramiXExtension)' and does not generate any warnings.
Fixes: xorg/xserver#590
Signed-off-by: Matt Turner <mattst88@gmail.com>
Separate each statement of the form "assert(a && b);" into "assert(a);"
and "assert(b);" for more precise diagnostics, except for this clever
use in drmmode_display.c where it was used to pass a hint to developers:
assert(num_infos <= 32 && "update return type");
We hide CWBackingStore from the screen hook if nothing's actually
changing, which means compChangeWindowAttributes no longer needs to
compare the requested state with the present one.
Terms:
dev->last.valuator[] is the last value given to us by the driver
dev->valuator.axisVal[] is the last value sent to the client
dev->last.scroll[] is the abs value of the scroll axis as given by the driver,
used for button emulation calculation (and the remainder)
This function updates the device's last.valuator state based on the current
master axis state. This way, relative motion continues fluidly when switching
between devices. Before mouse 2 comes into effect, it's valuator state is
updated to wherever the pointer currently is so the relative event applies on
top of that.
This can only work for x/y axes, all other axes aren't guaranteed to have the
same meaning and/or may not be present:
- xtest device: no valuator 2
- mouse: valuator 2 is horizontal scroll axis
- tablet: valuator 2 is pressure
Scaling the current value from the pressure range into the range for
horizontal scrolling makes no sense. And it causes scroll jumps:
- scroll down, last.valuator == axisVal == 20
- xdotool click 1, the XTest device doesn't have that valuator
- scroll up
- updateSlaveDeviceCoords reset last.valuator to 0 (axisVal == 20)
- DeviceClassesChangedEvent includes value 20 for the axis
- event is processed, last.value changes from 0 to -1
- axisVal is updated to -1, causing a jump of -21
The same applies when we switch from tablet to mouse wheel if the pressure
value is 0 on proximity out (basically guaranteed). So let's drop this code
altogether and only leave the scaling for the relative x/y motion.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
The `LimitClient` is set once and for all at startup, whereas the
function `ResourceClientBits()` which returns the client field offset
within the XID based on the value of `LimitClient` can be called
repeatedly.
Small optimization, cache the result of `ilog2()`, that saves running
the same loop over and over each time `ResourceClientBits()` is called.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
If the server resets, most client workqueues are cleaned up as the
clients are killed.
The one exception is the server's client, which is exempt from
the killing spree.
If that client has a queued work procedure active, it won't get
cleared on reset.
This commit ensures it gets cleared too.
c67f2eac56 ("dix: always send focus event on grab change") made dix
always sent events when it's a NotifyGrab or NotifyUngrab, even if
from == to, because 'from' can just come from a previous XSetInputFocus
call.
However, when an application calls XGrabKeyboard several times on
the same window, we are now sending spurious FocusOut+FocusIn with
NotifyGrab, even if the grab does not actually change. This makes screen
readers for blind people spuriously emit activity events which disturb
screen reading workflow when e.g. switching between menus.
This commit avoids calling DoFocusEvents in that precise case, i.e. when
oldWin is a previous grab and the new grab is the same window.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The screensaver can regularly move its window to random offsets. It should
use the ConfigureWindow function instead of calling the Screen's MoveWindow
directly. Some MoveWindow implementations, such as compMoveWindow, rely on
Screen's ConfigNotify being called first as it happens in ConfigureWindow.
Reviewed-by: Adam Jackson <ajax@redhat.com>
This reverts commit b45c74f0f2.
It broke the cursor in other games. Apparently those use cursor data
with premultiplied alpha, but with some pixels having r/g/b values
larger than the alpha value (which corresponds to original r/g/b
values > 1.0), triggering the workaround.
Seems the cure turned out worse than the disease, so revert.
Bugzilla: https://bugs.freedesktop.org/108650
Turns out some apps (e.g. the Civilization VI game) use
non-premultiplied cursor data which doesn't have any pixels with 0 alpha
but non-0 non-alpha, but can still result in visual artifacts.
This uses the method suggested by Kamil in
https://bugs.freedesktop.org/92309#c19: check for pixels where any
colour component value is larger than the alpha value, which isn't
possible with premultiplied alpha.
There can still be non-premultiplied data which won't be caught by this,
but that should result in slightly incorrect colours and/or blending at
the worst, not wildly incorrect colours such as shown in the bug report
below.
Bugzilla: https://bugs.freedesktop.org/108355
Suggested-by: Kamil Paral <kamil.paral@gmail.com>
This hasn't done anything besides return TRUE in a long long time.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
This variable was no longer being read anywhere. MAXCLIENTS the macro is
the compile-time maximum limit, LIMITCLIENTS the macro is the default
limit, LimitClients the variable is the limit for the current server.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Coverity complains about a use after free in here after the
freeing, I can't follow the linked list so well, but whot
says the device can only be on one list once, so break should
fix it.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Not sure what if anything calls XSetDeviceModifierMapping() but this would've
failed all the time. check_modmap_change() returns Success but we were
treating it like a boolean. Fix this.
Reported-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
GLX registers an extension before we know if there are any screens that
can actually do it. It's inconvenient to shrink the extension list, so
instead allow the extension to simply zero out its base opcode to
indicate that it needed to panic and disable itself.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Focus events are useless when 'from' and 'to' are the same. But when
this is the result of a (Un)GrabKeyboard request, we should always send
them, including when the window manager had previously used XSetInputFocus
to specify the focus on a window which happens to be now taking a grab.
This is notably needed for window manager using XI to always get keyboard
events even during grabs, so they can determine exactly when grabbing is
active.
Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
../dix/getevents.c: In function ‘transformAbsolute’:
../dix/getevents.c:1195:28: warning: ‘oy’ may be used uninitialized in this function [-Wmaybe-uninitialized]
struct pixman_f_vector p = {.v = {*x, *y, 1} };
^
../dix/getevents.c🔢22: note: ‘oy’ was declared here
double x, y, ox, oy;
^~
This one is truly special. Even though both ox and oy are set and read
along the same paths, only oy is marked for this warning! Initializing
just oy = 0.0 fixes it entirely, but let's not make a weird thing
weirder.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
PtrCtrl really makes sense for relative pointing device only, absolute
devices such as touch devices do not have any PtrCtrl set.
In some cases, if the client issues a XGetPointerControl() immediatlely
after a ChangeMasterDeviceClasses() copied the touch device to the VCP,
a NULL pointer dereference will occur leading to a crash of Xwayland.
Check whether the PtrCtrl is not NULL in ProcGetPointerControl() and
return the default control values otherwise, to avoid the NULL pointer
dereference.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1519533
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
Roundhouse kick replacing the various (sizeof(foo)/sizeof(foo[0])) with
the ARRAY_SIZE macro from dix.h when possible. A semantic patch for
coccinelle has been used first. Additionally, a few macros have been
inlined as they had only one or two users.
Signed-off-by: Daniel Martin <consume.noise@gmail.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This allows making the master screen's pixmap_dirty_list entries
explicitly reflect that we're now tracking the root window instead of
the screen pixmap, in order to allow Present page flipping on master
outputs while there are active slave outputs.
Define HAS_DIRTYTRACKING_DRAWABLE_SRC for drivers to check, but leave
HAS_DIRTYTRACKING_ROTATION defined as well to make things slightly
easier for drivers.
Reviewed-by: Adam Jackson <ajax@redhat.com>
This appears to be essentially unused. The only known client-side
library for the SELinux extension is xcb, which does not look for the
name "Flask". The "SGI-GLX" alias for GLX appears to be a bit of
superstition at this point, NVIDIA's driver does not expose it and Mesa
does not check for it.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Acked-by: Keith Packard <keithp@keithp.com>
The SendEvent request holds xEvent which is exactly 32 bytes long, no more,
no less. Both ProcSendEvent and SProcSendEvent verify that the received data
exactly match the request size. However nothing stops the client from passing
in event with xEvent::type = GenericEvent and any value of
xGenericEvent::length.
In the case of ProcSendEvent, the event will be eventually passed to
WriteEventsToClient which will see that it is Generic event and copy the
arbitrary length from the receive buffer (and possibly past it) and send it to
the other client. This allows clients to copy unitialized heap memory out of X
server or to crash it.
In case of SProcSendEvent, it will attempt to swap the incoming event by
calling a swapping function from the EventSwapVector array. The swapped event
is written to target buffer, which in this case is local xEvent variable. The
xEvent variable is 32 bytes long, but the swapping functions for GenericEvents
expect that the target buffer has size matching the size of the source
GenericEvent. This allows clients to cause stack buffer overflows.
Signed-off-by: Michal Srb <msrb@suse.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
If the root window borderClip region is null, the PointInWindowIsVisible()
check fails if pointer warping is attempted on the root window, making
the warping operation bail out early.
Assume coordinates always lay inside the root window for this case,
the actual position will be clamped later within screen coordinates anyway.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Delay removing the client from these two queues until all potential
I/O has completed in case we mark the client as ready for reading or
with pending output during the close operation.
Bugzilla: https://bugs.freedesktop.org/100957
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Nick Sarnie <commendsarnex@gmail.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.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>
Found when the meson conversion set the symbol to defined, instead of
defined to 1.
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Most of this is a legacy of the old "extmod" design where you could load
_some_ extensions dynamically but only if the server had been built with
support for them in the first place.
Note that since we now only initialize the DPMS extension if at least
one screen supports it, we no longer need DPMSCapableFlag: if it would
be false, we would never read its value.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.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>
This touches everything that ends up in the Xorg binary; the big missing
part is GLX since that's all generated code. Cuts about 14k from the
binary on amd64.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
This will be used by in-server features that need to react to property
changes. The first one will be _XWAYLAND_ALLOW_COMMITS.
Signed-off-by: Adam Jackson <ajax@redhat.com>
[Pekka: add commit message body]
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
Instead of just the atom. No functional change.
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.co.uk>
The root window, and by extension any damage records referencing it,
may be destroyed before shared pixmaps referencing it, which resulted in
use-after-free / double-free in PixmapStopDirtyTracking.
Fixes: b5b292896f ("prime: Sync shared pixmap from root window instead of screen pixmap")
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
The screen pixmap doesn't receive updates while there's a Present flip
window.
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
A client which is attended while a grab is blocking execution of its
requests needs to be placed in the saved_ready_clients list so that it
will get scheduled once the grab terminates. Otherwise, if the client
never sends another request, there is no way for it to be placed in
the ready_clients list.
v2: Wrap comment above mark_client_saved_ready.
Remove test for OS_COMM_IGNORED which will always be true.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99333
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
The custom os/os.O library reuses *.o files of os/libos.la.
The current rule assumes automake puts all the objects into per-target
am__*_la_OBJECTS variable. At least with AC_REPLACE_FUNCS, this no
longer holds (as wanted objects are put into LTLIBOBJS instead).
Depend on automake's result, the *.la library instead, to express demand
of any its dependencies being built.
Should be fixing randomly occuring "undefined reference to `strlcpy'"
errors when linking Xvfb and other DDX-es that could use os.O.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Mihail Konev <k.mvc@ya.ru>
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>
I think it is possible that output could get queued to a client during
CloseDownClient. After it is removed from the pending queue, active
grabs are released, the client is awoken if sleeping and any work
queue entries related to the client are processed.
To fix this, move the call removing it from the output_pending chain
until after clientGone has been set and then check clientGone in
output_pending_mark.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1382444
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
[This was originally a workaround for a client-side resource leak:
http://lists.freedesktop.org/archives/xorg-devel/2012-November/034555.html
Obviously that's a broken app, but the performance problem it
illustrates - that walking the linked list ends up burning all your CPU
time - is real enough. - ajax]
v2: Replace with a shorter code sequence which computes the same
results for all but numBits == 7
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Add a valuator mask setter for setting absolute coordinate combined
with unaccelerated motion deltas. This will later be used by Xwayland
to combine a wl_pointer.motion() event with the unaccelerated delta of
a wp_relative_pointer.relative_motion() event.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
GetImage is allowed to return window border contents, so don't remove
that from the returned image.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This allows us to remove darwinEvents_lock() and darwinEvents_unlock()
and remove the serverRunning hack from dix
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This function will be called when a pointer is grabbed non-root window
set as the 'confineTo'. This will enable the ddx to handle the
confinement their own way.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
This new vfunc will be called, if set, after a client has issued a
WarpPointer request. This is necessary for implementing pointer warp
emulation in Xwayland.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Keith Packard <keithp@keithp.com>
pClient does not contain a live value after the transition to lists
https://bugs.freedesktop.org/show_bug.cgi?id=97765
Application Specific Information:
X.Org X Server 1.18.99.1 Build Date: 20160910
=================================================================
==16921==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000108ce3834 at pc 0x000108880766 bp 0x7000045f76c0 sp 0x7000045f76b8
READ of size 4 at 0x000108ce3834 thread T6
#0 0x108880765 in SmartScheduleClient dispatch.c:365
#1 0x10887ecc5 in Dispatch dispatch.c:422
#2 0x1088c05f1 in dix_main main.c:301
#3 0x1082aabba in server_thread quartzStartup.c:66
#4 0x7fffc5f16aaa in _pthread_body (libsystem_pthread.dylib+0x3aaa)
#5 0x7fffc5f169f6 in _pthread_start (libsystem_pthread.dylib+0x39f6)
#6 0x7fffc5f161fc in thread_start (libsystem_pthread.dylib+0x31fc)
Regressed-in: 8f1edf4bd3
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
This ensures that the deviceProc is never called while the input
thread is processing data from the device.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Currently with PRIME if we detect a secondary GPU,
we switch to using SW cursors, this isn't optimal,
esp for the intel/nvidia combinations, we have
no choice for the USB offload devices.
This patch checks on each slave screen if hw
cursors are enabled, and also calls set cursor
and move cursor on all screens.
Cc: Aaron Plattner <aplattner@nvidia.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
This is a preparation patch for adding prime hw-cursor support.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
Fix a couple of copy-and-paste errors preventing FocusIn grabs from working.
Perhaps the extension version should be bumped though to distinguish between
working and non-working extension versions.
Signed-off-by: Michael Thayer <michael.thayer@oracle.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Make sure the whole event is initialized, instead of leaving the pad
bytes unset.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Eliminates all of the fd_set mangling in the server main thread
v2: Listen for POLLOUT while writes are blocked.
v3: Only mark client not ready on EAGAIN return from read
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This converts the dispatch loop into using a list of ready clients
instead of an array. This changes the WaitForSomething API so that it
notifies DIX when a client becomes ready to read, instead of returning
the set of ready clients.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
The intermediate grabState, "GrabKickout", was used to trigger
dispatch into going back to WaitForSomething after doing a GrabServer
so that the set of ready clients would be recomputed to match what the
server should be processing. As we only process one client per
WaitForSomething call, we will always hit WaitForSomething after
finishing the current client, and so don't need any special case here.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Instead of having scheduling done in two places (one in
WaitForSomething, and the other in SmartScheduleClient), just stick
all of the scheduling in SmartScheduleClient.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This removes the last uses of fd_set from the server interfaces
outside of the OS layer itself.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
With no users of the interface needing the readmask anymore, we can
remove it from the argument passed to these functions.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
This new libXfont API eliminates exposing internal X server symbols to
the font library, replacing those with a struct full of the entire API
needed to use that library.
v2: Use libXfont2 instead of libXfont_2
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Some games incorrectly use non-premultiplied ARGB cursor data, presumably
because that's what Windows uses. On some hardware (and with SWcursor),
this breaks areas of the cursor which are supposed to be transparent
(and presumably also translucent areas, but that's less noticeable).
This change checks for pixels with alpha == 0 and any non-alpha component
!= 0. If any such pixel is found, the data is assumed to be
non-premultiplied and fixed up by multiplying the RGB components with the
alpha component.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92309
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
The screen block and wakeup handlers are the only ones which provide a
well known ordering between the wrapping layers; placing these as
close as possible to the server blocking provides a way for the driver
to control the flow of execution correctly.
Switch the shadow code to run in the screen block handler so that it
now occurrs just before the server goes to sleep.
Switch glamor to call down to the driver after it has executed its own
block handler piece, in case the driver needs to perform additional
flushing work after glamor has called glFlush.
These changes ensure that the following modules update the screen in
the correct order:
animated cursors (uses RegisterBlockAndWakeupHandlers dynamically)
composite (dynamic wrapping)
misprite (dynamic wrapping)
shadow (static wrapping)
glamor (static wrapping)
driver (static wrapping)
It looks like there's still a bit of confusion between composite and
misprite; if composite updates after misprite, then it's possible
you'd exit the block handler chain with the cursor left hidden. To fix
that, misprite should be wrapping during ScreenInit time and not
unwrapping. And composite might as well join in that fun, just to make
things consistent.
[v2] Unwrap BlockHandler in shadowCloseScreen (ajax)
[v3] ephyr: Use screen block handler for flushing changes
ephyr needs to make sure it calls glXSwapBuffers after glamor finishes
its rendering. As the screen block handler is now called last, we have
to use that instead of a registered block/wakeup handler to make sure
the GL rendering is done before we copy it to the front buffer.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
A single provider can be both a offload and source slave at the same time,
the use of seperate lists breaks in this case e.g. :
xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 0 name:modesetting
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 0 name:modesetting
xrandr --setprovideroutputsource 1 0x7b
xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 1 name:modesetting
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 1 name:modesetting
xrandr --setprovideroffloadsink 1 0x7b
xrandr --listproviders
Providers: number : 3
Provider 0: id: 0x7b cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 3 outputs: 2 associated providers: 2 name:modesetting
Provider 1: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 2 name:modesetting
Provider 2: id: 0x46 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 2 outputs: 5 associated providers: 2 name:modesetting
Not good. The problem is that the provider with id 0x46 now is on both
the output_slave_list and the offload_slave_list of the master screen.
This commit fixes this by unifying all 3 lists into a single slaves list.
Note that this does change the struct _Screen definition, so this is an ABI
break. I do not expect any of the drivers to actually use the removed / changed
fields so a recompile should suffice.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
There are no in-tree consumers of the audit hooks, and they are in any
case redundant with the dtrace dispatch hooks. Neither is there any
in-tree user of the core request dispatch hook. The extension hook is
only used for non-default security cases, but in the absence of LTO we
always have to take the function call into XaceHookDispatch to find out
that there's no callback registered.
Cc: Eamon Walsh <ewalsh@tycho.nsa.gov>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
This is an ABI break, in that we now pass NULL to a function that hasn't
accepted it before.
Alex Goins had a different patch for this but it wasn't symmetrical, it
freed something in a very different place than it allocated it, this
attempts to retain symmetry in the releasing of the backing bo.
v2: use a new toplevel API, though it still passes NULL to something
that wasn't expecting it.
v3: pass -1 instead of 0.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Alex Goins <agoins at nvidia.com>
In patch 137ac094e7, Adam moved an
expensive call to UpdateCurrentTime out of the main dispatch
loop. That's a good change as the original fix from Chase was a bit
expensive. However, it breaks grab processing and so a couple of the
calls to UpdateCurrenTime need to be removed.
Input event processing can generate a stream of events; a button press
that activates a grab will send a press followed by a sequence of
enter/leave events. All of these should have the same time stamp on
the wire as they occur at the 'same' time.
More importantly, the grab time recorded in the device is pulled from
currentTime after all of the events are delivered, so if currentTime
doesn't match the time in the device event, then future grab
modifications will fail as the time marked in the device will be
'later' than the grab time known to the client (which is defined as
the timestamp from the activating input event).
A bit of history here -- it used to be that currentTime was driven
*entirely* by input events; those timestamps didn't even have to be
related to the system time in any way. Then we started doing ICCCM
stuff and people got confused when PropertyNotify events would have
the same timestamp even when delivered minutes apart because no input
events were delivered.
We added code in the server to go update the time, but only if no
input events were pending (so that the clock "wouldn't" go
backwards). The only places where this is necessary is in request
processing which may generate an event with a timestamp, and there
only at the very top of the request processing code so that the whole
request would be processed at the 'same time', just like events.
cc: Chase Douglas <chase.douglas@canonical.com>
cc: Peter Hutterer <peter.hutterer@who-t.net>
cc: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Tested-by: Michel Dänzer <michel.daenzer@amd.com>
Acked-by: Peter Hutterer <peter.hutterer@who-t.net>
These are local to inputthread.c; the ones in globals.c aren't
declared in any header file.
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Now that input is threaded, malloc can be used at event time to resize
the touchpoint buffer as needed.x
v2: Remove "Need to grow the queue means dropping events."
from comment as it no longer applies. (Peter Hutterer)
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
The current SIGIO signal handler method, used at generation of input events,
has a bunch of oddities. This patch introduces an alternative way using a
thread, which is used to select() all input device file descriptors.
A mutex was used to control the access to input structures by the main and input
threads. Two pipes to emit alert events (such hotplug ones) and guarantee the
proper communication between them was also used.
Co-authored-by: Fernando Carrijo <fcarrijo@freedesktop.org>
Signed-off-by: Tiago Vignatti <tiago.vignatti@nokia.com>
v2: Fix non-Xorg link. Enable where supported by default.
This also splits out the actual enabling of input threads to
DDX-specific patches which follow
v3: Make the input lock recursive
v4: Use regular RECURSIVE_MUTEXes instead of rolling our own
Respect the --disable-input-thread configuration option by
providing stubs that expose the same API/ABI.
Respond to style comments from Peter Hutterer.
v5: use __func__ in inputthread debug and error mesages.
Respond to style comments from Peter Hutterer.
v6: use AX_PTHREAD instead of inlining pthread tests.
Suggested by Emil Velikov <emil.l.velikov@gmail.com>
v7: Use pthread_sigmask instead of sigprocmask when using threads
Suggested by Adam Jackson <ajax@redhat.com>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Reviewed-by: Adam Jackson <ajax@redhat.com>
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>
This changes XInput 2's propagation of NotifyPointer focus out events to
include the pointer window as well, similar to core events. This fixes
a potential permanent focus in GDK when the focus moves to PointerRoot.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=93539
Signed-off-by: Andrew Comminos <andrew@comminos.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
This was added in:
commit 312910b4e3
Author: Chase Douglas <chase.douglas@canonical.com>
Date: Wed Apr 18 11:15:40 2012 -0700
Update currentTime in dispatch loop
Unfortunately this is equivalent to calling GetTimeInMillis() once per
request. In the absolute best case (as on Linux) you're only hitting the
vDSO; on other platforms that's a syscall. Either way it puts a pretty
hard ceiling on request throughput.
Instead, push the call down to the requests that need it; basically,
grab processing and event generation.
Cc: Chase Douglas <chase.douglas@canonical.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Adam Jackson <ajax@redhat.com>
Enrico Weigelt, metux IT consult
Peter Hutterer
Wanli Niu
José Expósito
Alan Coopersmith
Yao Wei
Olivier Fourdan
Mike Gorse
Jeremy Huddleston Sequoia
Sultan Alsawaf
Michel Dänzer
Povilas Kanapickas
tholin
Matthieu Herrb
Alex Richardson
Ignacio Casal Quinteiro
Simon Ser
Dave Airlie
Aaron Plattner
Adam Jackson
Hans de Goede
Arthur Williams
Matt Turner
Adam Richter
Ray Strode
Samuel Thibault
Michal Srb
Marco Trevisan (Treviño)
Michel Dänzer
Eric Anholt
Emil Velikov
Giuseppe Bilotta
Daniel Martin
Nathan Kidd
Jan Beich
Carlos Garnacho
Keith Packard
Mihail Konev
Rui Matos
Peter Harris
Jonas Ådahl
Michael Thayer
Dave Airlie
Andrew Comminos