summaryrefslogtreecommitdiff
path: root/Xi
AgeCommit message (Collapse)AuthorFilesLines
2017-10-12Xi: fix wrong extra length check in ProcXIChangeHierarchy (CVE-2017-12178)Nathan Kidd1-1/+1
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com> Reviewed-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Nathan Kidd <nkidd@opentext.com> Signed-off-by: Julien Cristau <jcristau@debian.org> (cherry picked from commit 859b08d523307eebde7724fd1a0789c44813e821)
2017-10-12Xi: integer overflow and unvalidated length in (S)ProcXIBarrierReleasePointerNathan Kidd1-0/+5
[jcristau: originally this patch fixed the same issue as commit 211e05ac85 "Xi: Test exact size of XIBarrierReleasePointer", with the addition of these checks] This addresses CVE-2017-12179 Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com> Reviewed-by: Julien Cristau <jcristau@debian.org> Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com> Signed-off-by: Nathan Kidd <nkidd@opentext.com> Signed-off-by: Julien Cristau <jcristau@debian.org> (cherry picked from commit d088e3c1286b548a58e62afdc70bb40981cdb9e8)
2017-09-25Xi: Test exact size of XIBarrierReleasePointerMichal Srb1-3/+6
Otherwise a client can send any value of num_barriers and cause reading or swapping of values on heap behind the receive buffer. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 211e05ac85a294ef361b9f80d689047fa52b9076)
2017-09-25Xi: Do not try to swap GenericEvent.Michal Srb1-1/+9
The SProcXSendExtensionEvent must not attempt to swap GenericEvent because it is assuming that the event has fixed size and gives the swapping function xEvent-sized buffer. A GenericEvent would be later rejected by ProcXSendExtensionEvent anyway. 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> (cherry picked from commit ba336b24052122b136486961c82deac76bbde455)
2017-09-25Xi: Verify all events in ProcXSendExtensionEvent.Michal Srb1-5/+7
The requirement is that events have type in range EXTENSION_EVENT_BASE..lastEvent, but it was tested only for first event of all. 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> (cherry picked from commit 8caed4df36b1f802b4992edcfd282cbeeec35d9d)
2017-09-25Xi: Zero target buffer in SProcXSendExtensionEvent.Michal Srb1-1/+1
Make sure that the xEvent eventT is initialized with zeros, the same way as in SProcSendEvent. Some event swapping functions do not overwrite all 32 bytes of xEvent structure, for example XSecurityAuthorizationRevoked. Two cooperating clients, one swapped and the other not, can send XSecurityAuthorizationRevoked event to each other to retrieve old stack data from X server. This can be potentialy misused to go around ASLR or stack-protector. 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> (cherry picked from commit 05442de962d3dc624f79fc1a00eca3ffc5489ced)
2017-09-25Xi: Use WarpPointerProc hook on XI pointer warping implementationCarlos Garnacho1-0/+4
Just like we do with XWarpPointer's. 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> (cherry picked from commit 95febc42cadf392a888104ad6d5cf4f34fdde7d5)
2017-01-11Xi: when creating a new master device, update barries for all clientsPeter Hutterer1-2/+4
The previous code only worked when the barrier was created by the same client as the one calling XIChangeDeviceHierarchy. http://bugzilla.redhat.com/show_bug.cgi?id=1384432 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Daniel Stone <daniels@collabora.com> (cherry picked from commit d6a6e1d6abb110ff00ad31b94cd29d92ca7c71a5)
2017-01-11xwayland: Don't send KeyRelease events on wl_keyboard::leaveRui Matos1-9/+13
Commits 816015648ffe660ddaa0f7d4d192e555b723c372 and fee0827a9a695600765f3d04376fc9babe497401 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> (cherry picked from commit 5611585b87ce48428a66f98ece319a083f55d205)
2016-10-26ddx: add new call to purge input devices that weren't addedPeter Hutterer1-0/+14
Special case for the systemd-logind case in xfree86: when we're vt-switched away and a device is plugged in, we get a paused fd from logind. Since we can't probe the device or do anything with it, we store that device in the xfree86 and handle it later when we vt-switch back. The device is not added to inputInfo.devices until that time. When the device is removed while still vt-switched away, the the config system never notifies the DDX. It only runs through inputInfo.devices and our device was never added to that. When a device is plugged in, removed, and plugged in again while vt-switched away, we have two entries in the xfree86-specific list that refer to the same device node, both pending for addition later. On VT switch back, the first one (the already removed one) will be added successfully, the second one (the still plugged-in one) fails. Since the fd is correct, the device works until it is removed again. The removed devices' config_info (i.e. the syspath) doesn't match the actual device we addded tough (the input number increases with each plug), it doesn't get removed, the fd remains open and we lose track of the fd count. Plugging the device in again leads to a dead device. Fix this by adding a call to notify the DDX to purge any remainders of devices with the given config_info, that's the only identifiable bit we have at this point. https://bugs.freedesktop.org/show_bug.cgi?id=97928 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
2016-09-15Hold input lock while calling input device SetProperty callbackKeith Packard1-0/+2
This keeps the input driver SetProperty function from being called while input events are being processed. 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>
2016-08-16xinput: Let top-level dispatch generate the errorAdam Jackson1-2/+2
... instead of calling SendErrorToClient ourselves. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Daniel Stone <daniels@collabora.com>
2016-05-26Remove SIGIO support for input [v5]Keith Packard1-2/+2
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>
2016-05-11dix: Remove pointless client-state callbacksAdam Jackson1-15/+0
Private storage is pre-zeroed by the private system itself. Signed-off-by: Adam Jackson <ajax@redhat.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2016-05-04dix: Push UpdateCurrentTimeIf down out of the main loopAdam Jackson2-1/+7
This was added in: commit 312910b4e34215aaa50fc0c6092684d5878dc32f 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>
2016-04-19Xi: don't deliver emulated motion events for non-emulating touchesPeter Hutterer1-0/+3
The touchpoint knows whether it should be emulating or not and we have a check for that later. Check for this before we generate the event and try to deliver it, lest we trigger a bug warning. https://bugzilla.redhat.com/show_bug.cgi?id=1282252 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2015-11-24Input: Add focus-in event sourceDaniel Stone1-0/+4
Add a new event source type for keypress events synthesised from focus notifications (e.g. KeymapNotify from the parent server, when running nested). This is used to keep the keys-down array in sync with the host server's, without sending actual keypress events to clients. Signed-off-by: Daniel Stone <daniels@collabora.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2015-10-20Xi: Silence some tautological warningsJeremy Huddleston Sequoia1-4/+2
xichangehierarchy.c:424:23: warning: comparison of constant 536870911 with expression of type 'uint16_t' (aka 'unsigned short') is always false [-Wtautological-constant-out-of-range-compare,Semantic Issue] if (stuff->length > (INT_MAX >> 2)) ~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~ xichangehierarchy.c:438:26: warning: comparison of constant 536870911 with expression of type 'uint16_t' (aka 'unsigned short') is always false [-Wtautological-constant-out-of-range-compare,Semantic Issue] if ((any->length > (INT_MAX >> 2)) || (len < (any->length << 2))) ~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~ 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>
2015-06-18Xi: call UpdateDeviceState() even when the client is missingAlexander Volkov1-1/+2
The client window can be closed in the middle of a touch sequence, e.g. Qt 4 closes popup windows on MousePress and Qt 5.5 will do it on TouchBegin. In this case the state of mouse buttons will not be updated on TouchEnd because ProcessTouchEvent() calls UpdateDeviceState() only when the event has been sent to the client. It results in a stuck left mouse button. This patch leads to calling UpdateDeviceState() in case the client can't be found. Signed-off-by: Alexander Volkov <a.volkov@rusbitech.ru> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2015-06-10dix: Send KeyPress and KeyRelease events to the XACE_KEY_AVAIL hookAndrew Eikum1-0/+12
While it's documented in the XACE spec, the XACE_KEY_AVAIL hook is currently never actually invoked by the xserver. This hook was added in 13c6713c82 (25 Aug 2006), but as the keyboard processing was moved into XKB, the hook was forgotten and silently dropped. The code calling this hook was removed by 7af53799c (4 Jan 2009), but it was probably already unused before that. This patch re-adds support for this hook. The "count" hook parameter is unused. Signed-off-by: Andrew Eikum <aeikum@codeweavers.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-24 11:35:37 +0000