- Sep 13, 2013
-
-
Matt Dew authored
-
- Sep 09, 2013
-
-
I'm getting a error building xorg-server-1.14.1.902 with thelatest snapshot of gcc-4.8: input.c:225:43: error: array subscript is above array bounds [-Werror=array-bounds] This is because kdNumInputFds can become equal to KD_MAX_INPUT_FDS in KdRegisterFd(). This means that in KdUnregisterFd(), kdInputFds[j + 1] can be beyond the end of the array. Signed-off-by: Chris Clayton <chris2553@googlemail.com> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
-
- Aug 22, 2013
-
-
Matt Dew authored
-
- Aug 13, 2013
-
-
The old code was broken and allowed setting client version >= XIVersion, this was fixed in the previous patch, but updating the value for XIVersion broke the tests, so fix the tests too. 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> (cherry picked from commit b6e5c466)
-
Do not allow setting client version to an arbitrary value >= XIVersion. Fixes a test error with test/xi2/protocol-xiqueryversion.c, introduced by commit 4360514d "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> (cherry picked from commit 500e844a)
-
Peter Hutterer authored
This reverts commit cdcb7086.
-
- Jul 30, 2013
-
-
Peter Hutterer authored
As of 4360514d, XIQueryVersion supports requesting versions 2.2+ in random order, only 2.0 and 2.1 are restricted. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit a5abf790183798ad8aa2c29c056df3647777cfbd)
-
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> (cherry picked from commit 4360514d)
-
Peter Hutterer authored
XI 1.x only allows for first + num valuators, so if a device sends data for valuators 0 and 2+ only (i.e. valuator 1 is missing) we still need to get the data for that from somewhere. XI 1.x uses the hack of an unset valuator mask to get the right coordinates, i.e. we set the value but don't set the mask for it so XI2 events have the right mask. For an absolute device in relative mode, this broke in b28a1af5, the value was now always 0. This wasn't visible on the cursor, only in an XI 1.x client. The GIMP e.g. sees jumps to x/0 every few events. Drop the condition introduced in b28a1af5, data in valuators is always absolute, regardless of the mode. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 3d875663)
-
Peter Hutterer authored
grab->type is only non-zero for passive grabs. We're checking an active grab here, so we need to check if the touch mask is set on the grab. Test case: grab the device, then start two simultaneous touches. The grabbing client won't see the second touchpoints because grab->type is 0 and the second touch is not an emulating pointer. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 4fb686d6)
-
- Jul 26, 2013
-
-
Matt Dew authored
Merge branch 'server-1.14-touch-fixes' of git://people.freedesktop.org/~whot/xserver into server-1.14-branch
-
Matt Dew authored
-
Matt Dew authored
-
- Jul 17, 2013
-
-
Peter Hutterer authored
All callers currently ignore the new value, so this patch has no effect. Inverse call graph: DeliverTouchEmulatedEvent DeliverEmulatedMotionEvent Ignores value DeliverTouchBeginEvent DeliverTouchEvent DeliverTouchEvents Ignores value DeliverTouchEndEvent DeliverTouchEvent DeliverTouchEvents Ignores value Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Keith Packard <keithp@keithp.com> (cherry picked from commit 9978b57b)
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit fd5ea023)
-
Peter Hutterer authored
If a client calls XIGrabDevice in response to a ButtonPress event (regular event selection), the device will have a grab, but listener->grab is NULL. Check for that, to avoid logspam. [ 26293.863] (EE) BUG: triggered 'if (!pGrab)' [ 26293.863] (EE) BUG: grabs.c:256 in FreeGrab() [ 26293.863] (EE) [ 26293.863] (EE) Backtrace: [ 26293.864] (EE) 0: /usr/bin/Xorg (FreeGrab+0x54) [0x45d3fc] [ 26293.864] (EE) 1: /usr/bin/Xorg (UpdateTouchesForGrab+0x135) [0x447d4e] [ 26293.864] (EE) 2: /usr/bin/Xorg (ActivatePointerGrab+0x1ba) [0x447f3d] [ 26293.864] (EE) 3: /usr/bin/Xorg (GrabDevice+0x3e6) [0x4503bc] [ 26293.864] (EE) 4: /usr/bin/Xorg (ProcXIGrabDevice+0x1f9) [0x5981b1] [ 26293.865] (EE) 5: /usr/bin/Xorg (ProcIDispatch+0x78) [0x58aa17] [ 26293.865] (EE) 6: /usr/bin/Xorg (Dispatch+0x30d) [0x43347e] [ 26293.865] (EE) 7: /usr/bin/Xorg (main+0x61d) [0x498175] [ 26293.865] (EE) 8: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x3df5621b75] [ 26293.865] (EE) 9: /usr/bin/Xorg (_start+0x29) [0x423a19] [ 26293.866] (EE) 10: ? (?+0x29) [0x29] [ 26293.866] (EE) Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Keith Packard <keithp@keithp.com> (cherry picked from commit 0e3be0b2)
-
Peter Hutterer authored
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> (cherry picked from commit 8eeaa74b)
-
Peter Hutterer authored
This shouldn't have been in the patch Reported-by: Colin Harrison <colin.harrison@virgin.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Keith Packard <keithp@keithp.com> (cherry picked from commit c21344ad)
-
Peter Hutterer authored
Too many callers relied on the refcnt being handled correctly. Use a simple wrapper to handle that case. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 9a5ad653)
-
Peter Hutterer authored
ProcessTouchEvents() calls UDS for all touch events, but if the event type was switched to TouchUpdate(pending end) UDS is a noop. Daniel Drake found this can cause stuck buttons if a touch grab is activated, rejected and the touch event is passed to a regular listener. This sequence causes the TouchEnd to be changed to TouchUpdate(pending end). The actual TouchEnd event is later generated by the server once it is passed to the next listener. UDS is never called for this event, thus the button remains logically down. A previous patch suggested for UDS to handle TouchUpdate events [1], however this would release the button when the first TouchEvent is processed, not when the last grab has been released (as is the case for sync pointer grabs). A client may thus have the grab on the device, receive a ButtonPress but see the button logically up in an XQueryPointer request. This patch adds a call to UDS to TouchEmitTouchEnd(). The device state must be updated once a TouchEnd event was sent to the last grabbing listener and the number of grabs on the touchpoint is 0. [1] http://patchwork.freedesktop.org/patch/13464/ Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 35c2e263)
-
Peter Hutterer authored
The cursor is referenced during CopyGrab(), thus doesn't need to be handled manually anymore. It does need to be refcounted for temp grabs though. The oldGrab handling in ProcGrabPointer is a leftover from the cursor in the grab being refcounted, but the grab itself being a static struct in the DeviceIntRec. Now that all grabs are copied, this lead to a double-free of the cursor (Reproduced in Thunderbird, dragging an email twice (or more often) causes a crash). Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 48170210)
-
Peter Hutterer authored
A client may call XIGrabDevice twice, overwriting the existing grab. Thus, make sure we free the old copy after we copied it. Free it last, to make sure our refcounts don't run to 0 and inadvertantly free something on the way. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 3093f78d)
-
Peter Hutterer authored
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> (cherry picked from commit 2566bdd8)
-
Peter Hutterer authored
TouchListenerGone cleans up if a client disappears. Having this in FreeGrab() triggers cyclic removal of grabs, emitting wrong events. In particular, it would clean up a passive grab record while that grab is active. Move it to CloseDownClient() instead, cleaning up before we go. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 5b00fc52)
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 34c9b39d)
-
Peter Hutterer authored
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> (cherry picked from commit 395124bd)
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 925e3512)
-
Peter Hutterer authored
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 4980bcef)
-
Peter Hutterer authored
no functional changes Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit ccfa0f2d)
-
Peter Hutterer authored
Obsolete since 4bc2761a. This struct existed so copying a passive grab could be simply done by activeGrab = *grab and thus have a copy of the GrabPtr we'd get from various sources but still be able to check device->grab for NULL. Since 4bc2761a activeGrab is a pointer itself and points to the same memory as grabinfo->grab, leaving us with the potential of dangling pointers if either calls FreeGrab() and doesn't reset the other one. There is no reader of activeGrab anyway, so simply removing it is sufficient. Note: field is merely renamed to keep the ABI. Should be removed in the future. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 5363433a)
-
Peter Hutterer authored
No functional changes. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 7dbf6181)
-
Peter Hutterer authored
Change the single if condition in the loop body to a if (!foo) continue; and re-indent the rest. No functional changes. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit a71a2839)
-
Peter Hutterer authored
A sync grab is the owner once it gets events. If it doesn't replay the event it will get all events from this touch, equivalent to accepting it. If the touch has ended before XAllowEvents() is called, we also now need to send the TouchEnd event and clean-up since we won't see anything more from this touch. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 5174b1f9)
-
Peter Hutterer authored
No functional changes, this just enables it to be re-used easier. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit e7f79c48)
-
Peter Hutterer authored
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> (cherry picked from commit 0eb9390f)
-
Peter Hutterer authored
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> (cherry picked from commit a7d989d3)
-
Peter Hutterer authored
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> (cherry picked from commit 214d11d3)
-
Peter Hutterer authored
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> (cherry picked from commit 026627fe)
-
Peter Hutterer authored
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> (cherry picked from commit d9053481)
-
Peter Hutterer authored
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 9ad0fdb1. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 8b0d2104)
-