summaryrefslogtreecommitdiff
path: root/Xi/exevents.c
AgeCommit message (Collapse)AuthorFilesLines
2014-01-22Merge remote-tracking branch 'whot/for-keith'Keith Packard1-1/+18
2014-01-12Replace 'pointer' type with 'void *'Keith Packard1-6/+6
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-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-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 Hutterer1-1/+1
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: 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-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-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>
2013-03-25Xi: use a temp variable for the new listenerPeter Hutterer1-8/+10
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>
2013-03-25Xi: return !Success from DeliverTouchEmulatedEvent if we didn't deliverPeter Hutterer1-2/+2
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>
2013-02-08Xi: limit valuator copy to valuator array size (#59939)Peter Hutterer1-1/+1
mask[(MAX_VALUATORS + 7)/8] is larger than data[MAX_VALUATORS], so static code checkers think we may be running OOB on the data array. Mask is initialized to 0, so this should not happen, but change it anyway to shut up code analyzer noise. X.Org Bug 59939 <http://bugs.freedesktop.org/show_bug.cgi?id=59939> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
2013-01-09dix: add resource type to touch listenersPeter Hutterer1-7/+4
Instead of guessing what resource type the listener is and what property to retrieve, store the resource type in the listener directly. Breaks XIT test cases: TouchGrabTestMultipleTaps.PassiveGrabPointerEmulationMultipleTouchesFastSuccession Fixes https://bugs.freedesktop.org/show_bug.cgi?id=56557 Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Keith Packard <keithp@keithp.com> Reviewed-by: Chase Douglas <chase.douglas@ubuntu.com>
2013-01-09input: Record grab pointer in TouchListenerKeith Packard1-21/+6
This places a pointer to the grab related to a TouchListener directly in the TouchListener structure rather than hoping to find the grab later on using the resource ID. Passive grabs have resource ID in the resource DB so they can be removed when a client exits, and those resource IDs get copied when activated, but implicit grabs are constructed on-the-fly and have no resource DB entry. 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>
2012-12-19Merge remote-tracking branch 'whot/barriers'Keith Packard1-0/+47
Conflicts: Xi/xichangehierarchy.c Small conflict with the patch from Xi: don't use devices after removing them Was easily resolved by hand. Signed-off-by: Keith Packard <keithp@keithp.com>
2012-12-17Xi: if the device is currently grabbed, flag the barrier eventPeter Hutterer1-0/+3
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
2012-12-17Xi: deliver barrier events as grabbed events where necessaryPeter Hutterer1-3/+15
If the grab_window is the barrier window and the client owns the grab, deliver as normal grabbed event (respecting owner_events). Otherwise, deliver as usual. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Jasper St. Pierre <jstpierre@mecheye.net>
2012-12-17Add support for XI2.3: Pointer barrier events and releases.Jasper St. Pierre1-0/+32
This adds support for clients that would like to get a notification every time a barrier is hit, and allows clients to temporarily release a barrier so that pointers can go through them, without having to destroy and recreate barriers. Based on work by Chris Halse Rogers <chris.halse.rogers@canonical.com> Signed-off-by: Jasper St. Pierre <jstpierre@mecheye.net> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2012-12-12Xi: if a TouchEnd appears on a actively grabbing client, always acceptPeter Hutterer1-23/+32
Once the TouchEnd appears on the device, the touch is done. If the client still has a pointer grab, accept it to avoid clients with TouchOwnership selections to wait indefinitely for the actual touch event. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2012-12-12Xi: fix typo "mechansims" → "mechanisms"Peter Hutterer1-1/+1
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2012-11-20Don't use GetTouchEvents in EmitTouchEndThomas Jaeger1-14/+4
As before GetTouchEvents causes unwanted side effects. Add a new function GetDixTouchEnd, which generates a touch event from the touch point. We fill in the event's screen coordinates from the MD's current sprite position. Signed-off-by: Thomas Jaeger <ThJaeger@gmail.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2012-11-05Merge remote-tracking branch 'whot/for-keith'Keith Packard1-3/+9
2012-11-06Xi: Set modifier mask on touch eventsCarlos Garnacho1-0/+5
Button mask should be out-of-band with the emulated pointer events as touch devices don't truly have "buttons". Even though, it's handy to have the modifier mask from the paired keyboard on touch events. 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>
2012-11-06Xi: Update the device after delivering the emulated pointer event(#56558)Carlos Garnacho1-3/+4
Ensure emulated pointer events contain the state that applies before the event was processed, so the device state must be updated after delivering such emulated events. Co-authored-by: Peter Hutterer <peter.hutterer@who-t.net> 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>
2012-11-05Xi: fix fprint format warningYaakov Selkowitz1-1/+1
exevents.c: In function 'ProcessTouchEvent': exevents.c:1601:20: warning: too many arguments for format Signed-off-by: Yaakov Selkowitz <yselkowitz@users.sourceforge.net> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
2012-10-29Xi: don't deliver TouchEnd to a client waiting for TouchBegin (#55738)Peter Hutterer1-0/+5
If a client is still waiting for the TouchBegin, don't deliver a TouchEnd event. X.Org Bug 55738 <http://bugs.freedesktop.org/show_bug.cgi?id=55738> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Tested-by: Thomas Jaeger <thjaeger@gmail.com> Reviewed-by: Keith Packard <keithp@keithp.com>
2012-10-04Xi: Don't check for TOUCH_END, it's never setDaniel Drake1-2/+0
This flag is never set, so checking for it here means that we'll never release the simulated mouse button press after the user touches (and releases) the touchscreen for the first time. Fixes a problem where the XO laptop touchpad became totally unusable after touching the screen for the first time (since X then behaved as if the mouse button was held down all the time). Signed-off-by: Daniel Drake <dsd@laptop.org> Reviewed-by: Chase Douglas <chase.douglas@canonical.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2012-08-05Do sent TouchEnd to listeners that don't own an accepted touchDaniel d'Andrada1-0/+6
When the owner of a touch accepts it, the other listeners must receive a TouchEnd. Even though there's code implementing the logic above in ProcessTouchOwnershipEvent(), DeliverTouchEndEvent() was refusing to send those TouchEnd events in this situatuation. Signed-off-by: Daniel d'Andrada <daniel.dandrada@canonical.com> Reviewed-by: Chase Douglas <chase.douglas@canonical.com> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
2012-07-09Fix more poorly indented/wrapped comments & codeAlan Coopersmith1-7/+6
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com> Reviewed-by: Keith Packard <keithp@keithp.com> Tested-by: Daniel Stone <daniel@fooishbar.org>
2012-06-07Replace a few BUG_WARN with BUG_RETURN_VALPeter Hutterer1-15/+10
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
2012-05-17Xi: fix "shadows previous local" warningsPeter Hutterer1-29/+7
exevents.c: In function 'DeepCopyFeedbackClasses': exevents.c:272:20: warning: declaration of 'classes' shadows a previous local [-Wshadow] exevents.c:245:16: warning: shadowed declaration is here [-Wshadow] (and a few more like this) exevents.c: In function 'DeliverTouchEmulatedEvent': exevents.c:1442:27: warning: declaration of 'win' shadows a parameter [-Wshadow] exevents.c:1404:55: warning: shadowed declaration is here [-Wshadow] exevents.c:1475:28: warning: declaration of 'listener' shadows a parameter [-Wshadow] exevents.c:1403:62: warning: shadowed declaration is here [-Wshadow] xiselectev.c: In function 'ProcXISelectEvents': xiselectev.c:178:34: warning: declaration of 'dummy' shadows a previous local [-Wshadow] xiselectev.c:91:18: warning: shadowed declaration is here [-Wshadow] Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
2012-05-17dix: Move DeviceFocusEvent from Xi into enterleave.cPeter Hutterer1-234/+0
This is only called from the enterleave implementation, so move it and its helper functions to there. No functional changes. Fixes build error introduced in 31174565ec0090b4c03c9334c82878be2455f938 if building with '-Werror=implicit-function-declaration' Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> Reviewed-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Jeremy Huddleston <jeremyhu@apple.com>
2012-04-18Update device state including when touch record does not existChase Douglas1-3/+3
If a touch is physically active, the pointer core state should reflect that the first button is pressed. Currently, this only occurs when there are active listeners of the touch sequence. By moving the device state updating to the beginning of touch processing we ensure it is updated according to the processed physical state no matter what. Signed-off-by: Chase Douglas <chase.douglas@canonical.com> Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-22 07:35:13 +0000