summaryrefslogtreecommitdiff
path: root/Xi
AgeCommit message (Collapse)AuthorFilesLines
2015-04-21Convert top level extensions to new *allocarray functionsAlan Coopersmith3-9/+7
v2: remove now useless parentheses Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-04-21Let calloc handle multiplicationAlan Coopersmith1-2/+2
It's going to multiply anyway, so if we have non-constant values, might as well let it do the multiplication instead of adding another multiply, and good versions of calloc will check for & avoid overflow in the process. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Matt Turner <mattst88@gmail.com>
2015-01-07Fix subwindow in Xi emulated eventsOlivier Fourdan1-2/+3
Bug: 70790 Signed-off-by: Olivier Fourdan <fourdan@xfce.org>
2014-12-08Xi: unvalidated lengths in Xinput extension [CVE-2014-8095]Alan Coopersmith16-18/+90
Multiple functions in the Xinput extension handling of requests from clients failed to check that the length of the request sent by the client was large enough to perform all the required operations and thus could read or write to memory outside the bounds of the request buffer. This commit includes the creation of a new REQUEST_AT_LEAST_EXTRA_SIZE macro in include/dix.h for the common case of needing to ensure a request is large enough to include both the request itself and a minimum amount of extra data following the request header. Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
2014-05-23Xi: block SIGIOs while copying device classes aroundSteven McDonald1-0/+4
I've been seeing sporadic (anywhere from once every few days to 3-4 times a day) crashes and freezes in X. The problematic behaviour isn't always the same, but I chose a particular incident to debug, and found that X was segfaulting in updateMotionHistory, on line 575 of dix/getevents.c. After some further investigation, I found that the bug was being triggered when a SIGIO was received in DeepCopyPointerClasses, between the AllocValuatorClass call (line 540) and updating the to->valuator pointer (line 545). AllocValuatorClass calls realloc() on to->valuator, so between these lines, it's not guaranteed to point to allocated memory. It seems the SIGIO handler is calling updateMotionHistory, which is reading the memory pointed to by to->valuator and getting a wrong value for last_motion, which updates buff to point to wildly the wrong place and thus generates a segfault when a memcpy() is done into buff. I am attaching a patch which I've been running on that machine for the past three days, and haven't yet observed any more crashing or freezing behaviour. The patch simply calls OsBlockSIGIO while DeepCopyDeviceClasses is in progress, as the state of the X server's device data structures is not guaranteed to be in a consistent state during that time. Debian bug#744303 <https://bugs.debian.org/744303> Signed-off-by: Julien Cristau <jcristau@debian.org> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2014-05-08Xi: don't copy a DeviceEvent into an InternalEventPeter Hutterer1-8/+8
==26141== Invalid read of size 8 ==26141== at 0x58FAEA: DeliverEmulatedMotionEvent (exevents.c:1484) An InternalEvent is bigger than a DeviceEvent, thus copying one to the other reads past the allocated boundary. Shouldn't have any real effect since we shouldn't access anything past the DeviceEvent boundary if the event type is correct. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2014-03-27Build Xi/stubs.c once as a convenience library, rather than once for each ↵Jon TURNEY1-2/+3
DDX which wants to use it Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk> Reviewed-by: Gaetan Nadon <memsize@videotron.ca>
2014-03-12xkb: Repurpose XkbCopyDeviceKeymap to apply a given keymap to a deviceRui Matos1-1/+1
This will also make it useful for cases when we have a new keymap to apply to a device but don't have a source device. Reviewed-by: Kristian Høgsberg <krh@bitplanet.net> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2014-02-21Xi: check for invalid modifiers for XI2 passive grabsPeter Hutterer2-1/+6
The other values are checked correctly, but if a modifier was outside the allowed range, it would go unnoticed and cause a out-of-bounds read error for any mask equal or larger than 256. The DetailRec where we store the grab masks is only sized to 8 * sizeof(Mask). Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2014-02-04input: un-constify dev->namePeter Hutterer1-2/+2
Fallout from fecc7eb1cf66db64728ee2d68cd9443df7e70879, and reverts most of the rest of that patch. The device name is allocated and may even change during PreInit. The const warnings came from the test codes, the correct fix here is to fix the test code. touch.c: In function ‘touch_init’: touch.c:254:14: warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default] dev.name = "test device"; Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2014-02-04Xi: remove superfluous cast.Peter Hutterer1-1/+1
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2014-01-25Check for calloc() failure in add_master()Alan Coopersmith1-0/+4
Reported-by: Ilja Van Sprundel <ivansprundel@ioactive.com> Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2014-01-25Xi: fix modifier offset in XIPassiveGrab swapping functionPeter Hutterer1-1/+1
The request is followed by mask_len 4-byte units, then followed by the actual modifiers. Also fix up the swapping test, which had the same issue. Reported-by: Alan Coopersmith <alan.coopersmith@oracle.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2014-01-22Xi: Use 'void *' instead of 'Pointer' (which is going away)Keith Packard1-1/+1
There's no reason for XI to declare 'typedef char *Pointer' in a shared header file; assume it will eventually go away and stop using it here. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-01-22Merge remote-tracking branch 'whot/for-keith'Keith Packard1-1/+18
2014-01-12Replace 'pointer' type with 'void *'Keith Packard6-17/+17
This lets us stop using the 'pointer' typedef in Xdefs.h as 'pointer' is used throughout the X server for other things, and having duplicate names generates compiler warnings. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2014-01-12xi: More warning cleanup for inputKeith Packard2-3/+3
Lots more const char stuff. Remove duplicate defs of CoreKeyboardProc and CorePointerProc from test/xi2/protocol-common.c Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
2014-01-09Xi: Ensure DeviceChanged is emitted after grabs are deactivatedCarlos Garnacho1-1/+18
When a grab on a slave device is deactivated, the master device must be checked, just in case there were events from other devices while the slave device was stolen away by the passive grab. This may introduce misbehaviors on mismatching valuators and device features later on UpdateDeviceState(). Signed-off-by: Carlos Garnacho <carlosg@gnome.org> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-12-11Xi: ungrab device when releasing a passive grab without ButtonReleaseMask ↵Peter Hutterer1-1/+2
(#71878) If an touch triggers an async button grab and that grab does not have the ButtonReleaseMask set, the TouchEnd is never delivered, deliveries is 0 and the grab is never deactivated. If the grab is pointer async and keyboard sync, the keyboard events are stuck in EnqueueEvent until some other pointer event terminates the grab. Change this to check for the number of listeners. If we're about to deliver a TouchEnd to a passive pointer grab, the number of listeners is already 1 - pointer grabs always accept so other listeners were removed. X.Org Bug 71878 <http://bugs.freedesktop.org/show_bug.cgi?id=71878> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-12-11Xi: Don't ActivateEarlyAccept POINTER_REGULAR listenersBen Gamari1-1/+2
Bug #71878 describes a bug resulting in the server ceasing to respond to keyboard input after a touch event. The problem might be the following: DeliverTouchBeginEvent tries to deliver an event to a listener of type LISTENER_POINTER_REGULAR, taking the following if branch, if (listener->type == LISTENER_POINTER_REGULAR || listener->type == LISTENER_POINTER_GRAB) { rc = DeliverTouchEmulatedEvent(dev, ti, ev, listener, client, win, grab, xi2mask); if (rc == Success) { listener->state = LISTENER_IS_OWNER; /* async grabs cannot replay, so automatically accept this touch */ if (dev->deviceGrab.grab && dev->deviceGrab.fromPassiveGrab && dev->deviceGrab.grab->pointerMode == GrabModeAsync) ActivateEarlyAccept(dev, ti); } goto out; } DeliverTouchEmulatedEvent succeeds. The deviceGrab meets all three of the conditions of the inner if, enters ActivateEarlyAccept which then fails due to, BUG_RETURN(ti->listeners[0].type != LISTENER_GRAB && ti->listeners[0].type != LISTENER_POINTER_GRAB); That is, despite listener->type == LISTENER_POINTER_REGULAR. With my non-existent knowledge of XINPUT, it seems like the solution here might be to only ActivateEarlyAccept when listener->type == LISTENER_POINTER_GRAB. Signed-off-by: Ben Gamari <bgamari.foss@gmail.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-10-29Xi: fix logic error when calculating emulated motion eventsPeter Hutterer1-1/+1
gcc -Wlogical-op exevents.c: In function 'DeliverEmulatedMotionEvent': exevents.c:1480:13: warning: logical 'or' of collectively exhaustive tests is always true [-Wlogical-op] The relevant snippet of exevents.c: 1479 if (ti->listeners[0].type != LISTENER_POINTER_REGULAR || 1480 ti->listeners[0].type != LISTENER_POINTER_GRAB) 1481 return; This condition was always true, causing dropped motion events. Reported-by: Alan Coopersmith <alan.coopersmith@oracle.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2013-08-30Xi: allow for XIAllowEvent requests larger than XI < 2.2 size (#68554)Peter Hutterer1-1/+1
XIAllowEvents changed length in XI 2.2 (for the touchid). A bug in libXi causes libXi to always use the new request length if the server supports 2.2, regardless of the client's XIQueryVersion request. The server takes the client's XIQueryVersion request into account though, resulting in a BadLength error if a 2.[0,1] client calls XIAllowEvents on a XI 2.2+ server. Can't fix this in libXi, so work around this in the server. X.Org Bug 68554 <http://bugs.freedesktop.org/show_bug.cgi?id=68554> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Adam Jackson <ajax@redhat.com>
2013-08-30Xi: replace loop with memsetPeter Hutterer1-4/+1
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Adam Jackson <ajax@redhat.com>
2013-08-01Xi: Clamp XIClient maximal version to XIVersionMaarten Lankhorst1-17/+14
Do not allow setting client version to an arbitrary value >= XIVersion. Fixes a test error with test/xi2/protocol-xiqueryversion.c, introduced by commit 4360514d1c "Xi: Allow clients to ask for 2.3 and then 2.2 without failing" Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-07-26Xi: Allow clients to ask for 2.3 and then 2.2 without failingKeith Packard1-6/+30
This allows different sub-systems within the same application to request different Xi versions without either getting old behaviour everywhere or simply failing with a BadValue. Signed-off-by: Keith Packard <keithp@keithp.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-07-11dix: when ungrabbing an active grab, accept pointer grabs (#66720)Peter Hutterer1-12/+23
Ungrabbing a device during an active touch grab rejects the grab. Ungrabbing a device during an active pointer grab accepts the grab. Rejection is not really an option for a pointer-emulated grab, if a client has a button mask on the window it would get a ButtonPress emulated after UngrabDevice. That is against the core grab behaviour. X.Org Bug 66720 <http://bugs.freedesktop.org/show_bug.cgi?id=66720> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
2013-05-15Xi: fix warning - remove unused 'rc'Peter Hutterer1-1/+0
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-05-10Xi: check for HAS_ACCEPTED only for grab listenersPeter Hutterer1-1/+1
If we have one listener left but it's not a grab, it cannot be in LISTENER_HAS_ACCEPTED state. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-05-10dix: always copy grabs, don't reference themPeter Hutterer1-2/+5
Introduced in xorg-server-1.13.99.901-2-g9ad0fdb. Storing the grab pointer in the listener turns out to be a bad idea. If the grab is not an active grab or an implicit grab, the pointer stored is the one to the grab attached on the window. This grab may be removed if the client calls UngrabButton or similar while the touch is still active, leaving a dangling pointer. To avoid this, copy the grab wherever we need to reference it later. This is also what we do for pointer/keyboard grabs, where we copy the grab as soon as it becomes active. Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-05-10dix: AllocGrab can copy if an argument is passed inPeter Hutterer4-4/+4
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-05-10dix: move EmitTouchEnd to touch.cPeter Hutterer1-31/+4
No functional changes, this just enables it to be re-used easier. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-05-10Xi: Don't emit a TouchEnd event to a frozen devicePeter Hutterer1-0/+4
EmitTouchEnd calls DeliverTouchEvents directly instead of through public.processInputProc. If a device is frozen, the TouchEnd is processed while the device is waiting for a XAllowEvents and thus ends the touch point (and the grab) before the client decided what to do with it. In the case of ReplayPointer, this loses the event. This is a hack, but making EmitTouchEnd use processInputProc breaks approximately everything, especially the touch point is cleaned up during ProcessTouchEvents. Working around that is a bigger hack than this. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-05-10Xi: use public.processInputProc to replay the touch historyPeter Hutterer1-3/+5
If a device is frozen in results to a grab, we need to enqueue the events. This makes things complicated, and hard to follow since touch events are now replayed in the history, pushed into EnqueueEvent, then replayed later during PlayReleasedEvents in response to an XAllowEvents. While the device is frozen, no touch events are processed, so if there is a touch client with ownership mask _below_ the grab this will delay the delivery and potentially screw gesture recognition. However, this is the behaviour we have already anyway if the top-most client is a sync pgrab or there is a sync grab active on the device when the TouchBegin was generated. (also note, such a client would only reliably work in case of ReplayPointer anyway) Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-05-10Xi: when punting to a new owner, always create TouchEnd eventsPeter Hutterer1-5/+14
If a touch is pending_finish and we just punted it to the next owner, that client must receive a TouchEnd event. If we just punted to the last owner and that owner not a touch grab, we need to end the touch since this is the last event to be sent, and the client cannot accept/reject this. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-05-10Xi: save state for early acceptancePeter Hutterer1-3/+3
Delivering an event changes the state to LISTENER_IS_OWNER and we thus lose the information of early acceptance. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-05-10Xi: if a passive async grab is activated from an emulated touch, acceptPeter Hutterer1-1/+7
Async grabs cannot replay events, they cannot reject, so we can do an early accept here. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-05-10Xi: fix lookup in ActivateEarlyAcceptPeter Hutterer1-8/+7
ActivateEarlyAccept() can only be called from a grabbing client, so we can ignore the rest. And it's easy enough to get the client from that since 9ad0fdb135a1c336771aee1f6eab75a6ad874aff. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-05-10Xi: update the core listener state if we delivered the touch eventPeter Hutterer1-7/+9
If a TouchBegin is sent to a core client, that client is now the owner. By the time the TouchEnd is being processed, the client cannot replay anymore, so we can assume that this is the final touch end and we can clean up the touch record. Note: DeliverTouchEmulatedEvent is called for all listeners and immediately bails out if the client is not the owner and thus shouldn't yet get the event. Thus, check the return code. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-05-10Xi: if we delivered a TouchEnd to a passive grab, end itPeter Hutterer1-3/+2
ef64b5ee97099618cf2e2cbbd3e471095695ae24 (which introduced the TOUCH_CLIENT_ID check) has a wrong assumption that generated touch events (TOUCH_CLIENT_ID) should not terminate passive grabs. This is untrue, a TouchEnd may be generated in response to a TouchReject higher up. If we _deliver_ an event to a client, terminate the passive grab. This requires us to count the actually delivered events too (first hunk). Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-05-10Xi: not having an ownership mask does not mean automatic acceptancePeter Hutterer1-1/+1
If we only have a single touch-grabbing client, setting the client as owner would clean up the touch once the TouchEnd was processed. If the client then calls XIAllowTouches() it will receive a BadValue for the touch ID (since the internal record is already cleaned up). Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-05-10input: print warnings if drivers don't initialize properlyPeter Hutterer1-6/+10
If drivers supply incorrect values don't just quietly return False, spew to the log so we can detect what's going on. All these cases are driver bugs and should be fixed immediately. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Dave Airlie <airlied@redhat.com>
2013-05-07Xi: free barrier code at reset timePeter Hutterer3-2/+16
==29423== 16 bytes in 1 blocks are definitely lost in loss record 73 of 328 ==29423== at 0x4A06B6F: calloc (vg_replace_malloc.c:593) ==29423== by 0x5987C0: XIBarrierInit (xibarriers.c:908) ==29423== by 0x58F370: XInputExtensionInit (extinit.c:1300) ==29423== by 0x4F33C3: InitExtensions (miinitext.c:337) ==29423== by 0x4997DB: main (main.c:208) Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-05-07Xi: always return BadMatch for XTest devices ChangeDeviceControl requestsPeter Hutterer3-0/+13
The only controls that still do something are DEVICE_RESOLUTION and DEVICE_ENABLE. XTest devices have no resolution to change, and they cannot be disabled. So skip the lot, and prevent a crash in the DDX when it's trying to de-reference pInfo->control_proc on device with no pInfo struct. Likewise, don't allow setting device mode or the valuators. XTest pointers are always relative, they don't have a mode. Test cases: xts5/XI/ChangeDeviceControl (1/10) xts5/XI/SetDeviceValuators (1/6) and a few others Reported-by: Knut Petersen <Knut_Petersen@t-online.de> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-05-07Xi: fix comment - XI2 grabs aren't keysym grabsPeter Hutterer1-2/+1
Comment dates back to a pre-release version of XI2 that supported keysym grabs. That never made it into a release, it was ditched before. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-04-15Never try to execute BellProcPtr NULL.Knut Petersen1-1/+2
This prevents xts XI/XDeviceBell-2 test from segfaulting the server. Signed-off-by: Knut Petersen <Knut_Petersen@t-online.de> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-04-15Xi: fix swapped grab mode args for keyboard devices in XIGrabDeviceRui Matos1-2/+13
The protocol says that the grab_mode argument applies to the device being grabbed and paired_device_mode to the paired master device. GrabDevice() however takes in a pointer mode and a keyboard mode and so we have to swap the values according the type of device being grabbed. 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>
2013-04-11Xi: Do not handle ET_TouchOwnership in ProcessTouchEventMaarten Lankhorst1-20/+22
The event struct is different, causing memory corruption on 1.13 and 1.14, as can be witnessed in https://bugs.freedesktop.org/show_bug.cgi?id=56578 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-04-11Xi: Use correct destination when swapping barrier eventsKeith Packard1-18/+18
Write the swapped values to the destination rather than the source. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2013-03-25Xi: add a comment to make a condition a bit clearerPeter Hutterer1-0/+1
The commit message to 676447190190d8546165e21be242cf16dd69f5ae explains it, but that doesn't stop the WTF moment when reading the code. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Keith Packard <keithp@keithp.com>
2013-03-25Xi: compress two if statements with the same bodyPeter Hutterer1-7/+3
We do the same thing here, compress them into one body. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Keith Packard <keithp@keithp.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-21 15:42:38 +0000