- 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)
-
Peter Hutterer authored
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> (cherry picked from commit d08bae29)
-
Peter Hutterer authored
ef64b5ee (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> (cherry picked from commit 81554d27)
-
Peter Hutterer authored
If the device is currently grabbed as the result of a passive grab activating, do not prepend that grab to the listeners (unlike active grabs). Otherwise, a client with a passive pointer grab will prevent touch grabs from activating higher up in the window stack. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> (cherry picked from commit 363b6387)
-
Peter Hutterer authored
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> (cherry picked from commit 9cc45c18)
-
Peter Hutterer authored
Instead of accessing ti->listener[0] all the time. No functional changes. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Keith Packard <keithp@keithp.com> (cherry picked from commit fc504a44)
-
- Jul 12, 2013
-
-
Aaron Plattner authored
There's no point in turning on outputs connected to GPU screens during initial configuration. Not only does this cause them to just display black, it also confuses clients when these screens are attached to a master screen and RandR reports that the outputs are already on. Also, don't print the warning about no outputs being found on GPU screens, since that's expected. Signed-off-by: Aaron Plattner <aplattner@nvidia.com> Reviewed-by: Dave Airlie <airlied@gmail.com> (cherry picked from commit dbfeaf70)
-
Dave Airlie authored
I didn't think we needed this before, but after doing some more work with reverse optimus it seems like it should be called. Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit f2fd8ec3)
-
Dave Airlie authored
this allows the pixmap dirty helper to be used for reverse optimus, where the GPU wants to copy from the shared pixmap to its VRAM copy. [airlied: slave_dst is wrong name now but pointless ABI churn at this point] Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 8fcb9d91)
-
Dave Airlie authored
scrn->display is a property of the main screen really, and we don't want to have the GPU screens use it for anything when picking modes or a front buffer size. This fixes a bug where when you plugged a display link device, it would try and allocate a screen the same size as the current running one (3360x1050 in this case), which was too big for the device. Avoid doing this and just pick sizes based on whats plugged into this device. Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit 16077b81)
-
Dave Airlie authored
We should have no problem allowing output/offload from the same slave, I asserted here, but in order to implement reverse optimus this makes perfect sense. (reverse optimus is intel outputting to nvidia). Reviewed-by: Keith Packard <keithp@keithp.com> Signed-off-by: Dave Airlie <airlied@redhat.com> (cherry picked from commit f0d0d75b)
-